3 Commits (cef7ad77985fe9fd9521b093831e2869bd905fcc)

Author	SHA1	Message	Date
Andy Wilkinson	196f92bd42	Exclude commons-logging to the extent that even Gradle’s happy ... 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	11 years ago
Phillip Webb	c719ab7aee	Exclude commons-logging from starter POMs ... 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	11 years ago
Craig Walls	f006b1231c	Add Spring Social autoconfiguration	11 years ago