[jira] Issue Comment Edited: (ARCHETYPE-179) repo1 is hardcoded into internal catalog

["Brent N Atkinson (JIRA)" <ji...@codehaus.org>]

    [ 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/15/08 11:03 PM:
----------------------------------------------------------------------

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?

      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 local 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