Gradle hasn’t different exclusion semantics to Maven. In Maven you can
exclude spring-core’s commons-logging dependency once and it’ll be
honoured even if you have multiple transitive routes to commons-logging
via spring-core. In Gradle you have to exclude commons-logging from
everything that has a transitive spring-core dependency. To make matters
worse this doesn’t only apply to dependencies and exclusions declared in
build.gradle but also to dependencies and exclusions declared in the pom
files of the artifacts that a Gradle build depends upon.
In short, to make our starters work as intended with Gradle, this commit
adds many, many exclusions for commons-logging. It also removes
commons-logging exclusions from spring-boot-dependencies’
<dependencyManagement> as they have no effect with Gradle and their
presence can cause us to miss required exclusions in a starter
Fixes#987
Update all relevant starter POMs to include a `spring-core` dependency
with an exclusion on `commons-logging`. This prevents `commons-logging`
and `jcl-over-slf4j` from both being on the classpath.
Also add enforcer rules to ensure that commons-logging doesn't sneak
back in, and that there is no dependency convergence. (some additional
libraries were required in spring-boot-dependencies)
Tested with a sample maven project as well as using the `spring jar`
command.
Fixes gh-985
This commit harmonizes the dependency management of internal modules
so that versions can be omitted everywhere. Update the maven coordinates
to provide the full groupId for consistency
There was an issue with the generated poms for the dependency
tools (I'm not sure the generation step works if you don't
do "mvn clean"). Anyway I verified that it works and removed
the (now) unnecessary provided dependency from spring-boot-cli.
Fixes gh-362
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Dave Syer
Artem Bilan
Spring Buildmaster
Phillip Webb