Maven Archetype

repo1 is hardcoded into internal catalog

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0-alpha-4
  • Component/s: Generator
  • Labels:
    None
  • Number of attachments :
    0

Description

The repository URL should not be hardcoded into the internal catalog - it is looking at repo1, when really it should be looking at the repository defined by central (ie, the one in my settings file that points to my internal repository proxy). So, it needs to honour settings. I believe the catalog should specify an id and a url - and if the id exists use that instead (and if not, fall back to the URL).

Issue Links

Activity

Hide
Raphaël Piéroni added a comment -

Fixed since revision 663729
The internal catalog is fixed

The test case retrieving the catalog from wiki also.
It also tries for each archetype defined to use it with first RELEASE then the defined version.

Show
Raphaël Piéroni added a comment - Fixed since revision 663729 The internal catalog is fixed The test case retrieving the catalog from wiki also. It also tries for each archetype defined to use it with first RELEASE then the defined version.
Hide
Brent N Atkinson added a comment - - edited

I am not so sure this issue is closed. Unless I am completely missing the point, the issue doesn't appear to be with the internal catalog. After peeking at the trunk (at the time of this post), the RemoteCatalogArchetypeDataSource still doesn't provide equivalent functionality as the getRemoteFile method in the WagonManager api (in the artifact module).

http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java?view=markup

It appears that archetype plugin isn't using the abstractions for artifact repositories for resolving the catalogs and is instead writing a new mechanism. This is troubling in that the existing abstractions ensured that things like password protected repositories (and mirrors) would function properly.

The archetype artifacts seem to resolve ok as long as a repository url is not specified in the catalog. The plugin uses the normal artifact api for resolution when no repo is specified in the catalog. Because I use my internal artifact proxy as a mirror for central, using an unprotected archetype catalog void of repo attributes, I am able to fully utilize the new plugin with a protected artifact proxy by specifying the catalog via -DarchetypeCatalog=http://my-unprotected-catalog-without-repo-attributes.

Because the repository configuration isn't in line with the typical Maven methodology, the plugin doesn't provide the same level of functionality as Maven itself. It also requires using command line arguments and a completely different configuration mechanism.

Consider the following: if catalogs were retrieved as artifacts, you could override the archetype plugin's default catalog by specifying an artifact reference (and perhaps a URL to locate the resource in the artifact jar). This would still allow using custom catalogs but it would be using the proven artifact resolution scheme. Authentication, proxies, mirrors, etc. would work correctly and it wouldn't require special configuration. Multiple repositories would be supported as they already are - by specifying another repository in the POM. This would also allow for a pre-configured Maven distribution with a profile to override the default catalog, and configuration would be consistent with all other Maven plugins. This would provide the same functionality, and it makes sense in terms of what Maven already does well. As it stands now, the 2.0+ plugin seems to be IDE-centric and a simplistic (maybe even broken) Maven plugin.

Before this plugin was released, I was really impressed with how coherent Maven was. I would like to help return the tool to that status. How can I help?

Show
Brent N Atkinson added a comment - - edited I am not so sure this issue is closed. Unless I am completely missing the point, the issue doesn't appear to be with the internal catalog. After peeking at the trunk (at the time of this post), the RemoteCatalogArchetypeDataSource still doesn't provide equivalent functionality as the getRemoteFile method in the WagonManager api (in the artifact module). http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java?view=markup It appears that archetype plugin isn't using the abstractions for artifact repositories for resolving the catalogs and is instead writing a new mechanism. This is troubling in that the existing abstractions ensured that things like password protected repositories (and mirrors) would function properly. The archetype artifacts seem to resolve ok as long as a repository url is not specified in the catalog. The plugin uses the normal artifact api for resolution when no repo is specified in the catalog. Because I use my internal artifact proxy as a mirror for central, using an unprotected archetype catalog void of repo attributes, I am able to fully utilize the new plugin with a protected artifact proxy by specifying the catalog via -DarchetypeCatalog=http://my-unprotected-catalog-without-repo-attributes. Because the repository configuration isn't in line with the typical Maven methodology, the plugin doesn't provide the same level of functionality as Maven itself. It also requires using command line arguments and a completely different configuration mechanism. Consider the following: if catalogs were retrieved as artifacts, you could override the archetype plugin's default catalog by specifying an artifact reference (and perhaps a URL to locate the resource in the artifact jar). This would still allow using custom catalogs but it would be using the proven artifact resolution scheme. Authentication, proxies, mirrors, etc. would work correctly and it wouldn't require special configuration. Multiple repositories would be supported as they already are - by specifying another repository in the POM. This would also allow for a pre-configured Maven distribution with a profile to override the default catalog, and configuration would be consistent with all other Maven plugins. This would provide the same functionality, and it makes sense in terms of what Maven already does well. As it stands now, the 2.0+ plugin seems to be IDE-centric and a simplistic (maybe even broken) Maven plugin. Before this plugin was released, I was really impressed with how coherent Maven was. I would like to help return the tool to that status. How can I help?

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: