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
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]