There was a problem with the Gradle plugin packaging application
dependencies in WEB-INF/lib-provided when only the servlet container
and its dependencies should be packaged there. See #1064 for details.
This commit adds two tests, one for Tomcat and one for Jetty, to
verify that only the expected entries appear in WEB-INF/lib-provided.
Closes#1071
Previously, the versionManagement configuration was resolved as part of
the Boot Gradle plugin being applied. This meant that no dependencies
could be added to it and attempting to do so would result in a failure:
“You can't change a configuration which is not in unresolved state”.
This commit updates ApplyExcludeRules to wrap its processing in a
before resolve action. This defers the resolution of the
versionManagement configuration until one of the project’s other
configurations is being resolved. Fixes#1077
In addition to the above, the transitive exclusions that the Gradle
plugin provides were being lost if custom version management provided
a version for the same dependency. This commit updates
AbstractDependencies to preserve the exclusions from an existing
dependency declaration while using the version from the newer
dependency. This ensures that the exclusions remain while allowing
versions to be overridden. Fixes#1079
Refactor dependency-tools to restore API compatibility with Spring
Boot 1.0. This should reduce reflection hacks that tools such as Gretty
would otherwise have to make.
See gh-1035
We've had problems with the starters when used with Gradle. They have
been pulling in commons-logging (#987) and the wrong version of Spring
(#1028) due to Gradle's different exclusion and dependency resolution
semantics.
This commit adds some integration tests that use Gradle's tooling API
to take each starter in turn and build a Gradle project that depends
upon it. The build looks at the transitive dependencies and checks
that neither commons-logging nor any Spring modules with the wrong
version are present.
Closes#1036
