maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schulte (JIRA)" <>
Subject [jira] Commented: (MNG-3090) Nearest dependency, which is not included by a filter, wins, although a farthest dependency, which is included by the same filter, does not win.
Date Sun, 08 Jul 2007 04:17:13 GMT


Christian Schulte commented on MNG-3090:

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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message