Michael Osipov commented on MNG-4142:

First of all, thank you [~carlspring] for the great analysis on the issue: 
there is no conneciton to classifiers. I have tested the sample project with 
3.0.5, 3.2.5, 3.3.9 and 3.4.0-SNAPSHOT. This issue still persists, now the bad 
thing: this issue is not rooted in Maven but in Aether, it rejects to 
redownload the snapshot. The root cause is the [update 
 of the remote repository set in the POM. The first check is done 
 which handles over to 

My questions are:

1. Why are the snapshots arleady in the repo, usecase, state?
2. What is your expected behavior? If the artifact is not yet in the local repo 
it has to pulled no matter what?

> Maven doesn't try to download SNAPSHOT artifacts, if you've installed them 
> locally
> ----------------------------------------------------------------------------------
>                 Key: MNG-4142
>                 URL: https://issues.apache.org/jira/browse/MNG-4142
>             Project: Maven
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 2.0.9, 2.0.10, 2.1.0
>         Environment: Java 5, Windows XP
>            Reporter: Arnaud HERITIER
>            Priority: Critical
>             Fix For: Issues to be reviewed for 3.x
>         Attachments: MNG-4142.patch, test-metadata-local-clover.zip
> When maven installs in the local repository an artifact with a classifier, 
> and not the principal artifact, it won't try in a reactor to download the 
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in 
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of 
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
>   Try downloading the file manually from the project website.
>   Then, install it using the command:
>       mvn install:install-file 
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1 
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>       mvn deploy:deploy-file 
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1 
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency:
>         1) 
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
>         2) 
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> ----------
> 1 required artifact is missing.
> for artifact:
>   org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
>   central (http://maven-proxy.groupe.generali.fr/all),
>   remote-repo 
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it 
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I 
> thought it was due to a problem with metadata sent by archiva, but after 
> migrating to nexus the problem always occurs. 
> I don't know if the problem is in metadata or in the reactor itself. I think 
> it is the second one. There are many issues opened about the reactor and 
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.

This message was sent by Atlassian JIRA

Reply via email to