[
http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101625
]
Christian Schulte commented on MNG-3090:
----------------------------------------
Reading
http://docs.codehaus.org/x/IGU#DependencyMediationandConflictResolution-Scoperesolution
I think that since the dependency management can now be used to control scopes
and versions of all dependencies, including transitive dependencies, scope
updates can simply be discarded. I took a look at various issues regarding
transitive dependencies and this scope update thing really seems to be a work
around for the missing manageArtifact() from the dependency management in
previous releases. Also looking at all the changes of DefaultArtifactCollector
I think updating the scope only was needed since dependency management could
not be used ? What people were requesting was exactly what the testcase does.
Getting a farther transitive dependency when the nearer would be excluded for
some reason when the farther would not. Also, if I get it right, the current
code seems to not do, what the comments in the code state. Look at these code
snippets from DefaultArtifactCollector:
if ( checkScopeUpdate( farthest, nearest, listeners ) )
{
Its the following comment which is confusing. It talks about an updated scope
of the nearest artifact but then disables this updated node in favour of the
farther!
// if we need to update scope of nearest to use
farthest scope, use the nearest version, but farthest scope
nearest.disable(); <-- gets disabled although the scope
got updated in checkScopeUpdate()
farthest.getArtifact().setVersion(
nearest.getArtifact().getVersion() ); <-- nearest version is used and farthest
scope since the farthest node is used, so the nearest node's scope would not
have to get updated anyways ?
fireEvent( ResolutionListener.OMIT_FOR_NEARER,
listeners, nearest, farthest.getArtifact() );
}
and in checkScopeUpdate():
if ( updateScope )
{
fireEvent( ResolutionListener.UPDATE_SCOPE, listeners, nearest,
farthestArtifact );
nearestArtifact.setScope( farthestArtifact.getScope() );
}
So when in checkScopeUpdate() the condition to update the scope is true, the
scope of the nearest artifact gets updated to the scope of the farthest - but
in the code calling checkScopeUpdate the updated nearest node will not get used
and gets disabled when this same condition holds true. This makes me think that
the updated scope of the nearest node never played any role since the node gets
disabled in favour of the farther which has the same scope the nearer got
updated with. If I get it right the whole checkScopeUpdate() method could be
discarded then and the node.filterTrail() method could be used similarly as
done in my patch. Can someone please explain why this scope update thing got
introduced and for what exactly it was needed ? Currently nodes which got
theire scope updated will actually not get used so there really is no scope
updating happening! It seems that it can be discarded in favour of
node.filterTrail() without braking existing builds then. Looking at the code of
DefaultArtifactCollector it seems that a node which got disabled once, will
never get enabled again. If this is true, the checkScopeUpdate() method could
be removed since all it does was forcing an update of the version of a farther
node to the version of a nearer. Nearest version wins, but farther node gets
used with the updated version of the nearer node. That's what the patch does
when checkScopeUpdate() returns false. All it would have to do additionally
would be to also update the version of the farther node with the one from the
nearer, which it currently does not. I will prepare another patch for review.
> Nearest dependency, which is not included by a filter, wins, although a
> farthest dependency, which is included by the same filter, does not win.
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-3090
> URL: http://jira.codehaus.org/browse/MNG-3090
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories
> Affects Versions: 2.0.7
> Reporter: Christian Schulte
> Attachments: maven-artifact-2.0.x.patch, testcase.tar.bz2
>
>
> There seems to be a problem with transitive dependencies and the nearest wins
> strategy. The nearest dependency wins, although a filter is in use which will
> not include that dependency when there is the same dependency at a deeper
> level, where it is included by the same filter. The nearest dependency gets
> discarded (e.g. is missing on the compile classpath) although the farthest
> dependency would have been included. Please see the comments in the attached
> patch.
--
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
