Provide dependency management for all of Jetty's modules

[wilkinsona]

As reported on Stackoverflow The current approach causes problems when a dependency pulls in a different version of Jetty and we end up with a mixture of versions on the classpath. For example:

These two dependencies:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>
    <dependency>
        <groupId>org.apache.solr</groupId>
        <artifactId>solr-core</artifactId>
        <version>4.7.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Produce this mixture of Jetty module versions:

$ mvn dependency:tree | grep org.eclipse.jetty:
[INFO] |  +- org.eclipse.jetty:jetty-webapp:jar:8.1.15.v20140411:compile
[INFO] |  \- org.eclipse.jetty:jetty-jsp:jar:8.1.15.v20140411: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:test
[INFO]    +- org.eclipse.jetty:jetty-server:jar:8.1.10.v20130312:test
[INFO]    +- org.eclipse.jetty:jetty-servlet:jar:8.1.10.v20130312:compile
[INFO]    +- org.eclipse.jetty:jetty-util:jar:8.1.15.v20140411:test
[INFO]    +- org.eclipse.jetty:jetty-xml:jar:8.1.10.v20130312:compile

A secondary problem here is that a number of the transitive dependencies of spring-boot-starter-jetty have become test-only dependencies; org.eclipse.jetty:jetty-server, for example. @snicoll Any ideas why that's happening?

[snicoll]

Sure, solr-core brings jetty dependencies itself. If you look at the dependency tree you have the first level dependencies (that is basically the dependencies that you've pasted above), the second-level being the direct dependencies of those two.

Assume that jetty-security is a third-level dependency via spring-boot-starter-jetty (a dependency of a dependency of spring-boot-starter-jetty) and that same artifact is a second-level dependency via solr-core (a dependency of solr-core) then that dependency is test scoped since it came via a test-scoped dependency.

That the's problem with the starter, you only define the intend and you're adding one level of indirection. One way to mitigate that would be to define the dependencies explicitly in the starter (instead of relying on transitive deps) but that's going to be a management nightmare.

[wilkinsona]

Thanks @snicoll. I knew that nearest-first applied to versions but didn't realise it applied to the scope as well. I can understand a test dependency becoming a compile dependency, but "downgrading" a transitive compile dependency to be a test-only dependency because it's nearest via a <scope>test</scope> dependency feels broken to me

[wilkinsona]

I've opened an issue against Maven for the dependencies in the compile scope being downgraded to the test scope.