[#MRM-770] Archiva web client does not recognize classifier - jira.codehaus.org

Archiva

Archiva web client does not recognize classifier

Created: 08/Apr/08 05:42 AM Updated: 28/Feb/10 11:03 PM

Component/s:

None

Affects Version/s:

1.0.1

Fix Version/s:

1.4

Time Tracking:

Not Specified

Environment:

« Hide

Apache Archiva 1.0.1
$ uname -a
Linux <hostname> 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_15-b04, mixed mode)
$ mvn -version
Maven version: 2.0.8
Java version: 1.5.0_15
OS name: "linux" version: "2.6.18-8.el5" arch: "amd64" Family: "unix"

Description

« Hide

As an example, I have put the following into my local Archiva repository:

reutersRFA:libFDacsLIB:5.1:solaris
reutersRFA:libFDacsLIB:5.1:linux_2x
reutersRFA:libFDacsLIB:5.1:linux_3x

The deploy command I use to achieve this was:

mvn deploy:deploy-file -Dfile=libFDacsLib.so -DgroupId=reutersRFA -DartifactId=libFDacsLib -Dversion=5.1 -Dpackaging=so -Dclassifier=solaris -DgeneratePom=true -DrepositoryId=archiva.default -Durl=http://invldnlspare1:9100/archiva/repository/internal/

et. sim for -Dclassifier=linux_2x and -Dclassifier=linux_3x

In the archiva repository filesystem I see:

$ find /appdata/archiva -name "libFDacsLib"
./data/repositories/internal/reutersRFA/libFDacsLib
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1.pom
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_3x.so.md5
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-solaris.so.sha1
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_2x.so
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1.pom.sha1
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_2x.so.sha1
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_3x.so.sha1
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_3x.so
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-solaris.so
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_2x.so.md5
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1.pom.md5
./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-solaris.so.md5
$

Note that there is only one *.pom, and there is no ".so" without a classifier extension.

In the web gui I can browse as far as

[top] / reutersRFA / libFDacsLib / 5.1

Inside this I see a POM Dependency Snippet which does not mention the classifier:

<dependency>
<groupId>reutersRFA</groupId>
<artifactId>libFDacsLib</artifactId>
<version>5.1</version>
<type>so</type>
</dependency>

I have a link to download the POM, but I have no link to download any actual artifact. No mention is made of "solaris", "linux_2x" or "linux_3x" anywhere on the web page.

I suspect the POM has been stripped of the classifier by archiva when maven deployed the artifact. As far as Archiva is concerned, there is only one POM which references an artifact that does not exist on the filesystem (no libFDacsLib.so file) since it's looking without the classifier extension.

Naturally I'd like to see a fix in a future version of Archiva if indeed Archiva is causing the problem. In the mean-time I would appreciate guidence as to whether I should create three separate POMs that specify the three classifier values to replace the existing POM in the archva repository filesystem.

Description

I've started using classifiers with some of my native libraries. The Web application does not represent the classifier, and the artifact is not downloadable from the web application. My builds are occurring correctly, so Maven has no difficulty retrieving the artifacts. As an example, I have put the following into my local Archiva repository: reutersRFA:libFDacsLIB:5.1:solaris reutersRFA:libFDacsLIB:5.1:linux_2x reutersRFA:libFDacsLIB:5.1:linux_3x The deploy command I use to achieve this was: mvn deploy:deploy-file -Dfile=libFDacsLib.so -DgroupId=reutersRFA -DartifactId=libFDacsLib -Dversion=5.1 -Dpackaging=so -Dclassifier=solaris -DgeneratePom=true -DrepositoryId=archiva.default -Durl=http://invldnlspare1:9100/archiva/repository/internal/ et. sim for -Dclassifier=linux_2x and -Dclassifier=linux_3x In the archiva repository filesystem I see: $ find /appdata/archiva -name "libFDacsLib" ./data/repositories/internal/reutersRFA/libFDacsLib ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1.pom ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_3x.so.md5 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-solaris.so.sha1 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_2x.so ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1.pom.sha1 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_2x.so.sha1 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_3x.so.sha1 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_3x.so ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-solaris.so ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-linux_2x.so.md5 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1.pom.md5 ./data/repositories/internal/reutersRFA/libFDacsLib/5.1/libFDacsLib-5.1-solaris.so.md5 $ Note that there is only one *.pom, and there is no ".so" without a classifier extension. In the web gui I can browse as far as [top] / reutersRFA / libFDacsLib / 5.1 Inside this I see a POM Dependency Snippet which does not mention the classifier: <dependency> <groupId>reutersRFA</groupId> <artifactId>libFDacsLib</artifactId> <version>5.1</version> <type>so</type> </dependency> I have a link to download the POM, but I have no link to download any actual artifact. No mention is made of "solaris", "linux_2x" or "linux_3x" anywhere on the web page. I suspect the POM has been stripped of the classifier by archiva when maven deployed the artifact. As far as Archiva is concerned, there is only one POM which references an artifact that does not exist on the filesystem (no libFDacsLib.so file) since it's looking without the classifier extension. Naturally I'd like to see a fix in a future version of Archiva if indeed Archiva is causing the problem. In the mean-time I would appreciate guidence as to whether I should create three separate POMs that specify the three classifier values to replace the existing POM in the archva repository filesystem.

Show »

Sort Order:

[ Permalink | « Hide ]

Brett Porter added a comment - 08/Apr/08 08:57 AM

in Maven, there is only one POM for a given 'coordinate' - classifiers are for derivative artifacts and so the project information should apply to all. That behaviour looks correct.

That said, Archiva should recognise the classifiers and list them under the downloads section, so I'll keep this open for fixing.

Does that make sense?

[ Permalink | « Hide ]

Robin Roos added a comment - 09/Apr/08 04:10 AM

That matches my understanding which is why I was reluctant to hack the POM on the repository filesystem. Clearly Maven can resolve these from Archiva without dificulty, so we're just talking about a web visualization issue.

Thanks.

[ Permalink | « Hide ]

Paolo Compieta added a comment - 17/Nov/09 02:29 AM

Hi,
that would be very handy: i've just introduced classifiers in my company to have the deploy-team download a particular EAR directly from the repo, but they still can't browse Archiva and find the artifact they need.

I could pass the actual link (so nothing blocker), but we have more than 25 ears and it takes me more than half an hour to write down all links.

One more thing: we are using different classifiers (activated by profiles) and one of them is default, so we do not publish the main artifact at all -i point this out to prevent problems in rendering the page without the main artifact.

Thanks!

[ Permalink | « Hide ]

Brett Porter added a comment - 23/Feb/10 02:49 AM

for testing

[ Permalink | « Hide ]

Brett Porter added a comment - 28/Feb/10 11:00 PM - edited

partially fixed in 1.4. The files are all listed for download correctly.

However, the download box shows them all as 'so' instead of indicating the classifier to help distringuish them. This should additionally be fixed.

As for the POM snippet - this is incorrect, but it is a result of the deploy-file plugin generating an incorrect POM (it should not have an so packaging if the artifact gives a classifier). We need not correct that in the UI.