You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Jason van Zyl (JIRA)" <ji...@codehaus.org> on 2005/12/20 04:46:37 UTC
[jira] Moved: (MASSEMBLY-6) dependency management in
AbstractUnpackingMojo is broken in the reactor
[ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org