Dropwizard-jetty/core pulls in javax.servlet transitively

At my workplace, we are currently transitioning from Dropwizard 1.x to 2.x (2.0.20 in particular). At the same time, we are replacing all the javax dependencies in our codebase with jakarta dependencies. One thing we noticed is that while Dropwiard has made an effort to depend only on jakarta dependencies, it still manages to transitively pull in some of the older javax dependencies, specifically javax.servlet:javax.servlet-api.



Now, I am not very comfortable with maven -- we use Gradle at work, so I can only provide a reproducible example in gradle terms, but I imagine everything is transferable. Take this example build.gradle file:

```

apply plugin: 'java'



dependencies {

    implementation 'io.dropwizard:dropwiard-core:2.0.25'

}

```

Then, I can execute the `:dependencies` task on the project and gradle will list a tree of all dependencies (including transitive) for the project. If we search specifically for javax dependencies using the following command, we can see that javax.servlet-api is in fact pulled in transitively (even though after looking through Dropwizard's POMs that there is a large effort to exclude javax.servlet-api from the transitive dependencies elsewhere). 

```

# Command:

./gradlew :dependencies --configuration runtimeClasspath | grep javax -B 5



# Output:

       +--- io.dropwizard:dropwizard-metrics:2.0.25

       |    +--- io.dropwizard:dropwizard-lifecycle:2.0.25

       |    |    +--- com.google.code.findbugs:jsr305:3.0.2

       |    |    +--- org.slf4j:slf4j-api:1.7.32

       |    |    +--- org.eclipse.jetty:jetty-server:9.4.43.v20210629

       |    |    |    +--- javax.servlet:javax.servlet-api:3.1.0

```

You can see jetty-server pulls in javax.servlet-api here, or at least that's what the dependency tree is saying here. In fact, in [dropwizard-lifecycle's POM](https://github.com/dropwizard/dropwizard/blob/v2.0.25/dropwizard-lifecycle/pom.xml#L24-L33) we can see that javax.servlet-api has been excluded. So why is it showing up here? Well, it's because there are other projects which depend on jetty-server, either directly or transitively which don't exclude javax.servlet-api. 



From what I could dig up, the two culprits (at least in DW 2.0.20) are explicit dependencies on metrics-jetty9 and jetty-security. It seems that DW 2.0.23 fixed the jetty9 issue with [this commit](https://github.com/dropwizard/dropwizard/commit/4307b06daf5d35d7297c71ecec3c1024105d7d02), though 2.0.25 still depends on jetty-security without excluding javax.servlet-api (jetty-security depends on jetty-server which depends on javax.servlet-api)



Take for example the following build.gradle file and we run the same command as above. 

```

apply plugin: 'java'



dependencies {

    implementation 'io.dropwizard:dropwiard-jetty:2.0.25'

}

```

Running the same command as above, we get the following output:

```

       +--- org.eclipse.jetty:jetty-io:9.4.43.v20210629

       |    \--- org.eclipse.jetty:jetty-util:9.4.43.v20210629

       +--- org.eclipse.jetty:jetty-security:9.4.43.v20210629

       |    \--- org.eclipse.jetty:jetty-server:9.4.43.v20210629

       |         +--- javax.servlet:javax.servlet-api:3.1.0

```



It appears DW depends on jetty-security twice, in [dropwizard-core](https://github.com/dropwizard/dropwizard/blob/v2.0.25/dropwizard-core/pom.xml#L122-L125) and [dropwizard-jetty](https://github.com/dropwizard/dropwizard/blob/v2.0.25/dropwizard-jetty/pom.xml#L56-L59). I believe we can fix this issue if we exclude javax.servlet-api from both of these dependency declarations. 



Personally, I find it quite crazy how much manual dependency management needs to go on to avoid pulling in these old javax dependencies. It seems like Dropwizard is going through a lot of work to exclude these dependencies individually from each transitive dependency which may still be depending on them. In gradle world, we can just do something like below and we don't have to worry about javax.servlet-api polluting our classpath ever. I find it hard to believe maven dependencyManagement can't do something similar (though, as I said, I am not skilled with working directly with maven). 

```

configurations.all {

    exclude group: 'javax.servlet'

}

```



Even if we are able to resolve this issue with these two new exclusions, I am still curious if there is a way to blanket exclude these javax dependencies from ever being pulled in transitively, so that so much manual (and error-prone) work doesn't need to happen to exclude them. Further, perhaps for even more confidence that these javax (and other) excluded dependencies aren't included in the in the final dependency tree, what if Dropwizard added to the build some kind of check on the resolved dependencies to ensure that the final classpath does not contain any offending dependencies? IMO if there is a problem with a POM in that it pulls in a javax dependency, the build should fail. 



Sorry for the long-winded issue. I wanted to provide as much detail as I could to try to best outline the issue I was seeing and provide reproducible examples and a potential solution (I haven't actually verified that the two exclusions I mentioned completely resolve the issue). 



Thank you

[]