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