You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@archiva.apache.org by nicolas de loof <ni...@gmail.com> on 2007/04/05 14:34:20 UTC

failure when serving maven2 plugin from a legacy repository

I'm using archiva to proxy http://dist.codehaus.org (maven1-legacy
repository)

This repo contains xdoclet2 maven plugin :
http://dist.codehaus.org/xdoclet/maven-plugins/

Having configured archiva as a mirror, maven tries to download :
http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.jar
that fails.

using
http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.maven-pluginworks
fine.

What is the expected behaviour :
1 - shouldn't dist.codehaus.org use a "maven-plugins" type ?
2 - how could archiva now we are expecting a maven plugin ?

For this second point, archiva could
- use the "*-plugin" pattern to detect the expected type, but this looks
like a hack
- read the POM for the requested artifact to get the type. Looks better but
more work to code...

Any suggestion ?

Re: failure when serving maven2 plugin from a legacy repository

Posted by nicolas de loof <ni...@gmail.com>.

AFAIK this extension map is used to convert a maven1 request to
"groupId/maven-plugins/xxx" to use a ".jar" extension.

The cas I get is requesting a maven2 plugin (type=maven-plugin) that is
deployed on a maven1 legacy repository (dist.codehaus.org). There is NO info
in the request that can be helpfull to now the type, expect some naming
conventions (artifactId = "maven-xx-plugin") OR ... read the artifact
related POM.

Please note reading the POM is allready used to find artifacts when maven1
requests a relocated resource (MRM-153), so this may be a nice solution to
apply when the artifact is not found at it's default location
(groupId/jars/).

Nico


2007/4/5, Joakim Erdfelt <jo...@erdfelt.com>:
>
> That is a failure in the packaging <-> file extension mapping facilities
> in archiva/trunk
>
> Other examples (from codein archiva branch):
>        typeToExtensionMap.put( "ejb-client", "jar" );
>        typeToExtensionMap.put( "ejb", "jar" );
>        typeToExtensionMap.put( "distribution-tgz", "tar.gz" );
>        typeToExtensionMap.put( "distribution-zip", "zip" );
>        typeToExtensionMap.put( "java-source", "jar" );
>        typeToExtensionMap.put( "aspect", "jar" );
>        typeToExtensionMap.put( "uberjar", "jar" );
>        typeToExtensionMap.put( "maven-plugin", "jar" );
>        typeToExtensionMap.put( "maven-archetype", "jar" );
>
> It (along with many other bugs) is being corrected in the archiva
> database refactor branch (highly unstable ATM).
>
> - Joakim
>
> nicolas de loof wrote:
> > I'm using archiva to proxy http://dist.codehaus.org (maven1-legacy
> > repository)
> >
> > This repo contains xdoclet2 maven plugin :
> > http://dist.codehaus.org/xdoclet/maven-plugins/
> >
> > Having configured archiva as a mirror, maven tries to download :
> >
> http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.jar
> >
> > that fails.
> >
> > using
> >
> http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.maven-pluginworks
> >
> > fine.
> >
> > What is the expected behaviour :
> > 1 - shouldn't dist.codehaus.org use a "maven-plugins" type ?
> > 2 - how could archiva now we are expecting a maven plugin ?
> >
> > For this second point, archiva could
> > - use the "*-plugin" pattern to detect the expected type, but this looks
> > like a hack
> > - read the POM for the requested artifact to get the type. Looks
> > better but
> > more work to code...
> >
> > Any suggestion ?
> >
>
>

Re: failure when serving maven2 plugin from a legacy repository

Posted by Joakim Erdfelt <jo...@erdfelt.com>.

That is a failure in the packaging <-> file extension mapping facilities
in archiva/trunk

Other examples (from codein archiva branch):
        typeToExtensionMap.put( "ejb-client", "jar" );
        typeToExtensionMap.put( "ejb", "jar" );
        typeToExtensionMap.put( "distribution-tgz", "tar.gz" );
        typeToExtensionMap.put( "distribution-zip", "zip" );
        typeToExtensionMap.put( "java-source", "jar" );
        typeToExtensionMap.put( "aspect", "jar" );
        typeToExtensionMap.put( "uberjar", "jar" );
        typeToExtensionMap.put( "maven-plugin", "jar" );
        typeToExtensionMap.put( "maven-archetype", "jar" );

It (along with many other bugs) is being corrected in the archiva
database refactor branch (highly unstable ATM).

- Joakim

nicolas de loof wrote:
> I'm using archiva to proxy http://dist.codehaus.org (maven1-legacy
> repository)
>
> This repo contains xdoclet2 maven plugin :
> http://dist.codehaus.org/xdoclet/maven-plugins/
>
> Having configured archiva as a mirror, maven tries to download :
> http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.jar
>
> that fails.
>
> using
> http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.maven-pluginworks
>
> fine.
>
> What is the expected behaviour :
> 1 - shouldn't dist.codehaus.org use a "maven-plugins" type ?
> 2 - how could archiva now we are expecting a maven plugin ?
>
> For this second point, archiva could
> - use the "*-plugin" pattern to detect the expected type, but this looks
> like a hack
> - read the POM for the requested artifact to get the type. Looks
> better but
> more work to code...
>
> Any suggestion ?
>