There are a few places where we have to exclude certain dependencies. When the third party dependency declares something we don't need then it can be done in spring-boot-dependencies.
There is a more tricky case when we want to harmonize the API jar of a specification. For instance, our JMS support replies on javax.jms:javax.jms-api but most of 3rd party integrations depend on another artifact coordinates.
Right now we exclude the JMS api version we don't want in the starter and in our own module (but not in the BOM).
I believe the reason why we do this is because users may want to use whatever artifact they want when they use our bom in case they don't use the starter. This principle falls apart when we want to integrate with a third party library (for instance a connection pool implementation). If a user adds it then they get the duplicate JMS api on the classpath (in essence, they have to do the same exclude we've applied in the starter).
It looks like a lot of work for no obvious benefit. I'd be tempted to apply those excludes consistently. If a user wants to use another JMS api jar, then they should add it explicitly (or simply add the standard we promote as we do in the starter).
Comment From: wilkinsona
Moving all the exclusions to the bom will potentially provide an additional benefit to Gradle users and bring us a step closer to being able to retire (some of) the dependency management plugin. Gradle 5's native bom support will apply exclusions from a bom unconditionally.
Comment From: snicoll
This is not as easy as it sounds. There are exclusions that we apply "locally" due to dependencies inconsistency. For instance this exclusion) that may be outdated.
We also apply exclude for things that come from a 3rd party bom that we import. For instance, jersey-spring4 as it still brings the previous Hibernate Validator artifact. For that one, we'd have to add a dependency alongside the BOM import.
I am not sure either that everything has to be moved to spring-boot-autoconfigure.
Comment From: philwebb
We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.