[jira] Issue Comment Edited: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=273211#comment-273211
]
Martin Todorov edited comment on MNG-4142 at 7/14/11 3:36 AM:
--
This bug/feature doesn't really have much to do with classifiers. I believe the
original bug report filer just thought it had something to do with the problem.
Perhaps somebody should rename the bug to "Maven doesn't try to download
SNAPSHOT artifacts, if you've installed them locally; even if you pass -U".
I believe that by using -U the local metadata should get "unlocked" (which
currently doesn't do this) for the locally installed SNAPSHOT artifacts.
was (Author: carlspring):
This bug/feature doesn't really have much to do with classifiers. I believe
the original bug report filer just thought it had something to do with the
problem.
Perhaps somebody should rename the bug to "Maven doesn't try to download
SNAPSHOT artifacts, if you've installed them locally; even if you pass -U".
I believe that by using -U the local metadata should get "unlocked" for the
locally installed SNAPSHOT artifacts.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://jira.codehaus.org/browse/MNG-4142
> Project: Maven 2 & 3
> 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]
>
> [ERROR] BUILD ERROR
> [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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
http://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223246#action_223246
]
Brian Laframboise edited comment on MNG-4142 at 5/31/10 3:42 PM:
-
I just ran into this issue myself (with Maven 2.2.1). A build on one of my
build machines was failing due to maven not downloading a newer version of a
dependency that was available on Nexus because it had previously installed an
earlier version of that same dependency into the local repository.
When I removed the true element from the metadata of the
non-updating dependency the problem went away - and dutifully came back when I
re-added it.
Peter, I agree - this is a scary problem for anybody trying to implement a
distributed build system. What I don't understand is why more people are not
encountering this issue.
For now I'll attempt a workaround this by adding a cron job, per build agent,
to frequently change back to false. If anybody has a better
suggestion, I'd love to hear it.
was (Author: brian.laframboise):
I just ran into this issue myself. A build on one of my build machines was
failing due to maven not downloading a newer version of a dependency that was
available on Nexus because it had previously installed an earlier version of
that same dependency into the local repository.
When I removed the true element from the metadata of the
non-updating dependency the problem went away - and dutifully came back when I
re-added it.
Peter, I agree - this is a scary problem for anybody trying to implement a
distributed build system. What I don't understand is why more people are not
encountering this issue.
For now I'll attempt a workaround this by adding a cron job, per build agent,
to frequently change back to false. If anybody has a better
suggestion, I'd love to hear it.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: http://jira.codehaus.org/browse/MNG-4142
> Project: Maven 2 & 3
> 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: 2.2.x (to be reviewed)
>
> 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]
>
> [ERROR] BUILD ERROR
> [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.
>
