[ 
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}
> <dependency>
>   <groupId>org.codehaus</groupId>
>   <artifactId>A</artifactId>
>   <version>1.0.0-20110705.132520-2</version>
> </dependency>
> {code}
> {code:title=Project C requires build number #1}
> <dependency>
>   <groupId>org.codehaus</groupId>
>   <artifactId>A</artifactId>
>   <version>1.0.0-20110705.132120-1</version>
> </dependency>
> {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

        

Reply via email to