Previously, the Spring Boot plugin would automatically apply the
dependency management plugin and import the spring-boot-dependencies
bom. This made it very difficult to use Spring Boot's plugin without
also using its dependency management. It also made it difficult to
see where the dependency management was coming from.
This commit updates the Spring Boot plugin so that it no longer
automatically applies the dependency management plugin. Instead, the
plugin now reacts to the dependency management plugin being applied
by importing the spring-boot-dependencies bom. Users that do not
wish to use Spring Boot's dependency management capabilities can now
do so by not applying the dependency management plugin.
Closes gh-3164
Previously, the BootRepackage task would take the output of a Jar
or War task and repackage it in a similar manner to Spring Boot's
Maven plugin. This caused several problems in Gradle including
broken up-to-date checks and a lack of configurability. See the issues
referenced below for full details.
This commit replaces BootRepackage with BootJar and BootWar
for building executable jars and wars respectively. BootJar extends
Gradle's standard Jar task and BootWar extends Gradle's standard War
task. This means that terms of configuration, the creation of
executable jars and wars is now as flexible as the creation of
standards jars and wars.
Closes gh-8167
Closes gh-8099
Closes gh-6846
Closes gh-5861
Closes gh-5393
Closes gh-5259
Closes gh-3931
Previously, bootRepackage's excludeDevtools property would be
overridden by the springBoot extension's excludeDevtools property.
This prevented devtools from being included by configuring it on the
repackaging task.
This commit corrects the logic so that the setting on the repackaging
task takes priority. It also adds some tests to verify the behaviour.
Closes gh-8308
In Gradle 3.3, when an API that will be removed in 4.0 is called, a
deprecation warning is output as part of the build. Users have noticed
his warning and, quite reasonably, complained about it. Unfortunately,
avoiding the warning requires the use of an API that was introduced in
Gradle 3.x which we can't use directly as we want to remain compatible
with Gradle 2.x.
This commit introduces the use of reflection to call
ProjectDependency.getTargetConfiguration() via reflection when it's
available (Gradle 3) and ProjectDependency.getProjectConfiguration()
when it's not (Gradle 2).
Closes gh-8154
Allow support for custom Lyout implementations with both the Maven
and Gradle plugin. Implementations of `LayoutFactory` can now be
specified to allow customization of the layout. In addition a
layout may now implement `CustomLoaderLayout` if it wishes to
write custom loader classes.
See gh-7263
