[jira] [Commented] (MNG-5129) Maven struggles while resolving locked snapshots by two or more simultaneously used projects.
[
https://issues.apache.org/jira/browse/MNG-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386730#comment-16386730
]
Jesse Glick commented on MNG-5129:
--
Sounds similar to MNG-4189.
> Maven struggles while resolving locked snapshots by two or more
> simultaneously used projects.
> -
>
> Key: MNG-5129
> URL: https://issues.apache.org/jira/browse/MNG-5129
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3
>Reporter: Christopher Klewes
>Priority: Blocker
> Attachments: maven-dependency-issue.zip
>
>
> This has to be explained with an easy example. Given that we have three
> projects (A, B and C). Both projects B and C has a dependency to a locked
> snapshot of project A.
> {code:title=Project B requires build number #2}
>
> org.codehaus
> A
> 1.0.0-20110705.132520-2
>
> {code}
> {code:title=Project C requires build number #1}
>
> org.codehaus
> A
> 1.0.0-20110705.132120-1
>
> {code}
> We now call {{dependency:resolve}} on each projects to resolve their
> dependencies from the repositories. As we can see in our local repository
> both versions are fetched and downloaded from their respective repository
> server. Unfortunately a last one wins conflict occurs. The project on which
> {{dependency:resolve}} is called last wins the race. Maven typically copies
> the latest fetched snapshot version (even if it's locked!) to the default
> version. Let's have a look at the folder structure:
> {code:title=Folder listing of the artifact dependency A
> (repository/org/codehaus/A/)}
> maven-metadata-local.xml
> maven-metadata-opensaga.xml
> maven-metadata-opensaga.xml.sha1
> A-1.0.0-20110705.132120-1.jar
> A-1.0.0-20110705.132120-1.pom
> A-1.0.0-20110705.132520-2.jar
> A-1.0.0-20110705.132520-2.pom
>
> A-1.0.0-SNAPSHOT.jar (the last fetched snapshot version)
> A-1.0.0-SNAPSHOT.pom
> {code}
> The last version will be copied to the file {{A-1.0.0-SNAPSHOT.jar}}. Maven
> references their dependencies to the file without the exactt
> timestamp/buildnumber. This fact make it impossible to develop the project B
> and C or even run them simultaneously, because only the last one wins.
> It would be mandatory to exactly reference the file with the timestamp of
> each project!
> What do you think on this issue? I submitted the project structure so you can
> easily reproduce this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] Commented: (MNG-5129) Maven struggles while resolving locked snapshots by two or more simultaneously used projects.
[
https://jira.codehaus.org/browse/MNG-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274133#comment-274133
]
Benjamin Bentmann commented on MNG-5129:
You can set the system property
{{aether.artifactResolver.snapshotNormalization=false}} on the commandline or
via MAVEN_OPTS, but whether all Maven plugins out there properly deal with this
situation, is a different story. Good luck.
> Maven struggles while resolving locked snapshots by two or more
> simultaneously used projects.
> -
>
> Key: MNG-5129
> URL: https://jira.codehaus.org/browse/MNG-5129
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3
>Reporter: Christopher Klewes
>Priority: Blocker
> Attachments: maven-dependency-issue.zip
>
>
> This has to be explained with an easy example. Given that we have three
> projects (A, B and C). Both projects B and C has a dependency to a locked
> snapshot of project A.
> {code:title=Project B requires build number #2}
>
> org.codehaus
> A
> 1.0.0-20110705.132520-2
>
> {code}
> {code:title=Project C requires build number #1}
>
> org.codehaus
> A
> 1.0.0-20110705.132120-1
>
> {code}
> We now call {{dependency:resolve}} on each projects to resolve their
> dependencies from the repositories. As we can see in our local repository
> both versions are fetched and downloaded from their respective repository
> server. Unfortunately a last one wins conflict occurs. The project on which
> {{dependency:resolve}} is called last wins the race. Maven typically copies
> the latest fetched snapshot version (even if it's locked!) to the default
> version. Let's have a look at the folder structure:
> {code:title=Folder listing of the artifact dependency A
> (repository/org/codehaus/A/)}
> maven-metadata-local.xml
> maven-metadata-opensaga.xml
> maven-metadata-opensaga.xml.sha1
> A-1.0.0-20110705.132120-1.jar
> A-1.0.0-20110705.132120-1.pom
> A-1.0.0-20110705.132520-2.jar
> A-1.0.0-20110705.132520-2.pom
>
> A-1.0.0-SNAPSHOT.jar (the last fetched snapshot version)
> A-1.0.0-SNAPSHOT.pom
> {code}
> The last version will be copied to the file {{A-1.0.0-SNAPSHOT.jar}}. Maven
> references their dependencies to the file without the exactt
> timestamp/buildnumber. This fact make it impossible to develop the project B
> and C or even run them simultaneously, because only the last one wins.
> It would be mandatory to exactly reference the file with the timestamp of
> each project!
> What do you think on this issue? I submitted the project structure so you can
> easily reproduce this issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
