[
https://jira.codehaus.org/browse/MNG-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359416#comment-359416
]
Robert Scholte commented on MNG-5739:
-------------------------------------
Ok , but in that case *don't* use the output of the
{{maven-dependency-plugin}}, since it's known that its output is often but not
always correct. Instead use the output from {{mvn -X}} as evidence.
Based on the title: be aware that a dependency can have exactly one scope. So
if you say in your pom that a compile-scoped dependency should get the
test-scope, then that is its new scope. Is that what's happening here?
> Adding a test dependency can move dependencies from the compile scope to the
> test scope
> ---------------------------------------------------------------------------------------
>
> Key: MNG-5739
> URL: https://jira.codehaus.org/browse/MNG-5739
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Reporter: Andy Wilkinson
> Attachments: pom.xml, test-scope-problem.zip
>
>
> I'm seeing some strange behaviour where the transitive dependencies of a
> test-scope dependency are causing transitive dependencies of a compile-scope
> dependency to become test-scoped.
> A pom with a single dependency on {{org.eclipse.jetty:jetty-webapp}} produces
> the following dependencies:
> {noformat}
> $ mvn dependency:tree | grep org.eclipse.jetty:
> [INFO] \- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
> [INFO] +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
> [INFO] | \- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
> [INFO] \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
> [INFO] \- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
> [INFO] \- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:compile
> [INFO] +-
> org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:compile
> [INFO] \-
> org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:compile
> [INFO] \-
> org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:compile
> {noformat}
> If I now add a test dependency on {{org.apache.solr:sole-core}}, a number of
> dependencies that were previously in the compile scope are now in the test
> scope:
> {noformat}
> $ mvn dependency:tree | grep org.eclipse.jetty:
> [INFO] +- org.eclipse.jetty:jetty-webapp:jar:8.1.10.v20130312:compile
> [INFO] | +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile
> [INFO] | \- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
> [INFO] +- org.eclipse.jetty:jetty-continuation:jar:8.1.10.v20130312:test
> [INFO] +- org.eclipse.jetty:jetty-deploy:jar:8.1.10.v20130312:test
> [INFO] +- org.eclipse.jetty:jetty-http:jar:8.1.10.v20130312:test
> [INFO] +- org.eclipse.jetty:jetty-io:jar:8.1.10.v20130312:test
> [INFO] +- org.eclipse.jetty:jetty-jmx:jar:8.1.10.v20130312:test
> [INFO] +- org.eclipse.jetty:jetty-security:jar:8.1.10.v20130312:compile
> [INFO] +- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
> [INFO] +- org.eclipse.jetty:jetty-util:jar:8.1.10.v20130312:compile
> {noformat}
> My understanding is that this is because the shortest route to the root of
> the hierarchy wins and, for a number of the Jetty dependencies, the shortest
> route is via the test-scoped {{org.apache.solr:sole-core}}. I can understand
> a test-scoped dependency being upgraded to the compile scope when a
> dependency is added, but downgrading a dependency from the compile scope to
> the test scope feels broken to me.
> I can work around the problem by using dependency management to force the
> dependencies into the compile scope, or by declaring direct dependencies on
> the transitive dependencies of {{org.eclipse.jetty:jetty-webapp}}, but both
> approaches require me to know what all those dependencies are and "duplicate"
> them in my pom, undermining the value of the dependencies being pulled in
> transitively in the first place.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
