[
http://jira.codehaus.org/browse/ARCHETYPE-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141928#action_141928
]
batkinson edited comment on ARCHETYPE-179 at 7/16/08 10:26 AM:
----------------------------------------------------------------------
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 the resource url in the 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?
was (Author: batkinson):
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. Having
said this, the archetype artifacts seem to resolve ok (as long as a repository
url is *not* specified in the catalog) because they use the artifact api for
resolution.
Also, without resolving the catalog using the artifact repository abstraction,
overriding the default catalog by preconfiguring maven settings seems to be
impossible (at least without a fragile hack). This makes this maven plugin very
unattractive for corporate-style usage.
Can I help in any way?
> repo1 is hardcoded into internal catalog
> ----------------------------------------
>
> Key: ARCHETYPE-179
> URL: http://jira.codehaus.org/browse/ARCHETYPE-179
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
> Reporter: Brett Porter
> Fix For: 2.0-alpha-4
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
