You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Jerome Lacoste (JIRA)" <ji...@codehaus.org> on 2005/11/16 12:41:07 UTC
[jira] Created: (MNG-1588) dependency management in AbstractUnpackingMojo is broken in the reactor
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-1588) dependency management in AbstractUnpackingMojo is broken in the reactor
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-1588?page=all ]
John Casey closed MNG-1588:
---------------------------
Assign To: John Casey
Resolution: Fixed
applied, with changes to the comments.
> 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
> Assignee: John Casey
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-1588) dependency management in AbstractUnpackingMojo is broken in the reactor
Posted by "Jerome Lacoste (JIRA)" <ji...@codehaus.org>.
[ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org