You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Christian Schulte (JIRA)" <ji...@codehaus.org> on 2007/07/06 02:25:13 UTC
[jira] Created: (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.
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
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
[jira] Updated: (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.
Posted by "Christian Schulte (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schulte updated MNG-3090:
-----------------------------------
Attachment: MNG-3090.patch
Patch to additionally update the version of the farther node with that from the nearer.
After removing the checkScopeUpdateMethod() and taking a look at the testcases which then fail, it is now clear what the scope updates are needed for.
> 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, MNG-3090.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
[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.
Posted by "Joerg Schaible (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101446 ]
Joerg Schaible commented on MNG-3090:
-------------------------------------
This might also be correlated to an issue I reported on the list just before M207 was released: http://article.gmane.org/gmane.comp.jakarta.turbine.maven.devel/79492
Since I could not reproduce it with a stripped down project, I did not open a separate JIRA issue. However, this issue is the show-stopper for us using M207.
I can confirm that Christian's test case works with M205 and fails for me with M206 + M207.
> 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
[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.
Posted by "Carlos Sanchez (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101421 ]
Carlos Sanchez commented on MNG-3090:
-------------------------------------
example or test?
> 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
>
>
> 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
[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.
Posted by "Mark Hobson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101439 ]
Mark Hobson commented on MNG-3090:
----------------------------------
This seems related to two areas I've been looking into:
1) First point in http://www.mail-archive.com/dev@maven.apache.org/msg68011.html
2) MNG-3089
> 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
[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.
Posted by "Christian Schulte (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101426 ]
Christian Schulte commented on MNG-3090:
----------------------------------------
Removing the dependencyManagement section from the testcase pom and adding the version and scope attributes to the other poms it also builds using 2.0.7. So it has to do with dependency management.
> 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
[jira] Updated: (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.
Posted by "Christian Schulte (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schulte updated MNG-3090:
-----------------------------------
Attachment: testcase.tar.bz2
Testcase for the attached patch. Trying to build this using maven-2.0.7 fails with
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Quick Start Archetype E
[INFO] task-segment: [install]
[INFO] ----------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to /home/schulte/Sources/testcase/e/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
/home/schulte/Sources/testcase/e/src/main/java/NewClass.java:[10,34] package org.apache.commons.logging does not exist
/home/schulte/Sources/testcase/e/src/main/java/NewClass.java:[22,8] cannot find symbol
symbol : variable LogFactory
location: class NewClass
Attaching the patch and rebuilding with the modified maven-2.0.8-SNAPSHOT does work. Seems to have something to do with the dependencyManagement and the checkScopeUpdate() method which will not to, what it did before manageArtifact() got introduced.
> 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
[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.
Posted by "Christian Schulte (JIRA)" <ji...@codehaus.org>.
[ 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
[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.
Posted by "Christian Schulte (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101424 ]
Christian Schulte commented on MNG-3090:
----------------------------------------
Will try to provide a test-case. Maybe it also has to do with the dependencyManagement section somehow. There seems to be no way to use a dependencyManagement section inside DefaultArtifactCollectorTest.
> 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
>
>
> 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
[jira] Updated: (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.
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated MNG-3090:
------------------------------
Fix Version/s: 2.0.x
> 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
> Assignee: Jason van Zyl
> Fix For: 2.0.x
>
> Attachments: maven-artifact-2.0.x.patch, MNG-3090.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
[jira] Updated: (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.
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl updated MNG-3090:
-------------------------------
Assignee: Jason van Zyl
> 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
> Assignee: Jason van Zyl
> Attachments: maven-artifact-2.0.x.patch, MNG-3090.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
[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.
Posted by "Christian Schulte (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_101423 ]
Christian Schulte commented on MNG-3090:
----------------------------------------
Seems to be related to MNG-1233 since it has to do with different scopes.
> 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
>
>
> 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