We have a library using Gradle that wraps the dropwizard lifecycle library. In the previously linked pom you can see that it specifies exlusions on org.eclipse.jetty.toolchain:jetty-servlet-api. Our library respects that inclusion, and does not pull in that excluded library when building.
Our main application that has our wrapping library as a gradle dependency however, does pull in the jetty-servlet-api.
It should properly honor such exclusions and if I just add a dependency on that library, the exclusion is also honored properly.
If it still comes in, you probably have some other dependency on it.
You can use dependencies and dependencyInsight tasks or a build --scan to investigate where the dependency comes from.
I’ve been looking at build scans quite a bit already but I’m still puzzled. Here’s a link.
The excluded dependency is org.eclipse.jetty.toolchain:jetty-servlet-api:4.0.6. It seems to come from org.eclipse.jetty:jetty-server:10.0.17, which comes from io.dropwizard.metrics:metrics-jetty10:4.2.21, which comes from io.dropwizard:dropwizard-core:3.0.3.
The strange this is that in the pom of dropwizard-core:3.03 there is an exclusion on the jetty-servlet-api (excerpt below:)
Actually, it is hard to say for me from the scan alone.
It could be some build logic that causes this.
It could also be that the trinetx-dropwizard dependency is doing something, but I cannot look at it as it is on a private repository. But at least it depends on io.dropwizard:dropwizard-core:3.0.3 and thus upgrades dropwizard-core opposed to the 3.0.0 that would just come through com.smoketurner:dropwizard-swagger:3.0.0-1.
And besides all that, you are using mavenLocal() in your build which is broken by design and should be avoided as hell, especially as first repostitory and especially without content filter. You can also read more about it at Declaring repositories. Besides that it makes builds slower, it also makes builds flaky. I’d recommend you remove that and then try again, could well be that then it works already.