[ http://jira.codehaus.org/browse/MNG-1588?page=all ]
Jerome Lacoste updated MNG-1588: -------------------------------- Attachment: MNG-1588.diff This fixes the issue, althought I believe it to not be the full correct fix. Once this is checked in, the priority can be downgraded from blocker to normal (or we create a separate issue for the remaining cleanup). > dependency management in AbstractUnpackingMojo is broken in the reactor > ----------------------------------------------------------------------- > > Key: MNG-1588 > URL: http://jira.codehaus.org/browse/MNG-1588 > Project: Maven 2 > Type: Bug > Components: maven-assembly-plugin > Versions: 2.0.1 > Reporter: Jerome Lacoste > Priority: Blocker > Fix For: 2.0.1 > Attachments: MNG-1588.diff > > > This problem only affects reactor builds. > MNG-1206 broke my build. The lines > String key = artifact.getGroupId() + ":" + > artifact.getArtifactId() + ":" + artifact.getVersion(); > > if ( !reactorArtifacts.containsKey( key ) && > !dependencies.containsKey( key ) ) > { > dependencies.put( key, artifact ); > } > Any dependency that is supposedly known by the reactor won't be included in > the project's dependencies. > So if you have: > moduleA > moduleB depends on moduleA > moduleA will be missing in the dependencies found by getDependencies() in an > assembly plugin used by moduleB, as it is already in the reactorArtifacts. > Not good when you want to use moduleA in your assembly :) > Also note that the key used doesn't take into account the type of the > artifact. That may be a problem on its own, perhaps with attached artifacts. > Shouldn't getDependencies() just work in the context of the reactor instead > of this particular mojo having to identify the relevant dependencies? > One thing is to fix that properly. In the mean time, I am leaning on removing > the check (!reactorArtifacts.containsKey( key )). > I'd rather have too many dependencies than not enough. Q: would this affect > the UnpackMojo ? > Related issue: I also find strange that we process all reactor dependencies. > I think this could lead to the situation where a dependency not referenced by > the pom but referenced by the assembly config file and referenced by a module > in the reactor which has not yet been built could be taken into account. We > should restrict the dependencies from the reactorProjects up to the current > project being built. > Basically: > moduleA depends on lib1 > moduleB depends on lib2 > When we are using the assembly in moduleA from the reactor, lib2 shouldn't be > in the list of dependencies. Today I think it is. > All in all I think the getDependencies() is not correct. I will try removing > the reactorArtifacts check for now, but it clearly could be improved. > We shouldn't even add dependencies of all reactorProjets. Those after the > current project should be discarded -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]