[ http://jira.codehaus.org/browse/MASSEMBLY-6?page=all ]
Jason van Zyl moved MNG-1588 to MASSEMBLY-6:
--------------------------------------------
Version: (was: 2.0.1)
Fix Version: (was: 2.0.1)
Component: (was: maven-assembly-plugin)
Workflow: jira (was: Maven)
Key: MASSEMBLY-6 (was: MNG-1588)
Project: Maven 2.x Assembly Plugin (was: Maven 2)
> dependency management in AbstractUnpackingMojo is broken in the reactor
> -----------------------------------------------------------------------
>
> Key: MASSEMBLY-6
> URL: http://jira.codehaus.org/browse/MASSEMBLY-6
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Jerome Lacoste
> Assignee: John Casey
> Priority: Blocker
> 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]
