[jira] Commented: (MNG-2409) @requiresDependencyResolution re-resolves transitive dependencies

["Jason van Zyl (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204225#action_204225 ] 

Jason van Zyl commented on MNG-2409:
------------------------------------

This is fixed as part of the work in 3.x. I don't think you really want to attempt to fix this in 2.x.

> @requiresDependencyResolution re-resolves transitive dependencies
> -----------------------------------------------------------------
>
>                 Key: MNG-2409
>                 URL: http://jira.codehaus.org/browse/MNG-2409
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 2.0.4
>            Reporter: Stepan Roh
>             Fix For: 3.x
>
>         Attachments: test.rdr.zip
>
>
> Consider this scenario:
> project A
> project B, depends on A
> project C, to be compiled, depends on B
> projects A and B are from artifact repository, project C is being compiled
> Let's say that before phase compile of project C my plugin is called which looks for all dependencies of C (in our case A and B) and change their file (Artifact.setFile()). All those dependencies are already resolved. Then compile:compile is run which has @requiresDependencyResolution compile which leads to A being re-resolved = it loses my file, but B retains it:
> original A.getFile() = a.jar
> original B.getFile() = b.jar
> changed A.getFile() = xa.jar
> changed B.getFile() = xb.jar
> after compile A.getFile() = a.jar
> after compile B.getFile() = xb.jar
> Attached archive contains all necessary source code (source of A, B, C and test Mojo) to recreate the situation. Just do:
> unzip test.rdr.zip
> cd test.rdr
> ( cd project-a; mvn install )
> ( cd project-b; mvn install )
> ( cd maven-refile-plugin; mvn install )
> ( cd project-c; mvn install )
> The output of last mvn install will be something like (edited for brevity):
> [INFO] [refile:set-file {execution: set}]
> [INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
> [INFO]   resolved: true
> [INFO]   file: .../project-b-1.0-SNAPSHOT.jar
> [INFO]   new file: .../project-b-1.0-SNAPSHOT.jar.new.jar
> [INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
> [INFO]   resolved: true
> [INFO]   file: .../project-a-1.0-SNAPSHOT.jar
> [INFO]   new file: .../project-a-1.0-SNAPSHOT.jar.new.jar
> [INFO] Compile classpath: [target\classes, .../project-b-1.0-SNAPSHOT.jar.new.jar, .../project-a-1.0-SNAPSHOT.jar.new.jar]
> [INFO] [refile:show-file {execution: show-before-compile}]
> [INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
> [INFO]   resolved: true
> [INFO]   file: .../project-b-1.0-SNAPSHOT.jar.new.jar
> [INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
> [INFO]   resolved: true
> [INFO]   file: .../project-a-1.0-SNAPSHOT.jar.new.jar
> [INFO] Compile classpath: [target\classes, .../project-b-1.0-SNAPSHOT.jar.new.jar, .../project-a-1.0-SNAPSHOT.jar.new.jar]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [refile:show-file {execution: show-after-compile}]
> [INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
> [INFO]   resolved: true
> [INFO]   file: .../project-b-1.0-SNAPSHOT.jar.new.jar
> [INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
> [INFO]   resolved: true
> [INFO]   file: .../project-a-1.0-SNAPSHOT.jar
> [INFO] Compile classpath: [target\classes, .../project-b-1.0-SNAPSHOT.jar.new.jar, .../project-a-1.0-SNAPSHOT.jar]
> ...
> As you can see after compile is run, project A's file is back to original value, but B retained new file. I think this is a strange behaviour and should be changed to act one way or another, preferably that already resolved dependencies are not re-resolved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira