Replace basic Gradle dependency management with use of separate plugin

This commit replaces Spring Boot's basic dependency management support
with separate dependency management plugin. This has a number of
benefits including:

1. A Maven bom can be used rather than a custom properties file
2. Dependency management is applied transitively rather than only to
   direct dependencies
3. Exclusions are applied as they would be in Maven
4. Gradle-generated poms are automatically configured with the
   appropriate dependency management

Closes gh-2133
This commit is contained in:
Andy Wilkinson
2015-03-18 17:08:07 +00:00
parent cb067ee00c
commit 2c3c62d71c
59 changed files with 132 additions and 1090 deletions

View File

@@ -165,8 +165,8 @@ Advanced configuration options and examples are available in the
[[build-tool-plugins-gradle-plugin]]
== Spring Boot Gradle plugin
The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, allowing you to
package executable jar or war archives, run Spring Boot applications and omit version
information from your `build.gradle` file for "`blessed`" dependencies.
package executable jar or war archives, run Spring Boot applications and use the
dependency management provided by `spring-boot-dependencies`.
@@ -201,12 +201,15 @@ If you are using a milestone or snapshot release you will also need to add appro
[[build-tool-plugins-gradle-dependencies-without-versions]]
=== Declaring dependencies without versions
The `spring-boot` plugin will register a custom Gradle `ResolutionStrategy` with your
build that allows you to omit version numbers when declaring dependencies to "`blessed`"
artifacts. To make use of this functionality, simply declare dependencies in the usual way,
but leave the version number empty:
[[build-tool-plugins-gradle-dependency-management]]
=== Dependency management
The `spring-boot` plugin automatically applies the
{dependency-management-plugin}/[Dependency Management Plugin] and configures in to import
the `spring-boot-starter-parent` bom. This provides a similar dependency management
experience to the one that is enjoyed by Maven users. For example, it allows you to omit
version numbers when declaring dependencies that are managed in the bom. To make use of
this functionality, simply declare dependencies in the usual way, but leave the version
number empty:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
@@ -218,12 +221,12 @@ but leave the version number empty:
----
NOTE: The version of the `spring-boot` gradle plugin that you declare determines the
actual versions of the "`blessed`" dependencies (this ensures that builds are always
repeatable). You should always set the version of the `spring-boot` gradle plugin to the
actual Spring Boot version that you wish to use. Details of the versions that are
provided can be found in the <<appendix-dependency-versions, appendix>>.
version of the `spring-boot-starter-parent` bom that is imported (this ensures that builds
are always repeatable). You should always set the version of the `spring-boot` gradle
plugin to the actual Spring Boot version that you wish to use. Details of the versions
that are provided can be found in the <<appendix-dependency-versions, appendix>>.
The `spring-boot` plugin will only supply a version where one is not specified. To
The dependency management plugin will only supply a version where one is not specified. To
use a version of an artifact that differs from the one that the plugin would provide,
simply specify the version when you declare the dependency as you usually would. For
example:
@@ -235,81 +238,8 @@ example:
}
----
[[build-tool-plugins-gradle-custom-version-management]]
==== Custom version management
If is possible to customize the versions used by the `ResolutionStrategy` if you need
to deviate from Spring Boot's "`blessed`" dependencies. Alternative version metadata
is consulted using the `versionManagement` configuration. For example:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
dependencies {
versionManagement("com.mycorp:mycorp-versions:1.0.0.RELEASE@properties")
compile("org.springframework.data:spring-data-hadoop")
}
----
Version information needs to be published to a repository as a `.properties` file. For
the above example `mycorp-versions.properties` file might contain the following:
[source,properties,indent=0,subs="verbatim,attributes"]
----
org.springframework.data\:spring-data-hadoop=2.0.0.RELEASE
----
The properties file takes precedence over Spring Boot's defaults, and can be used
to override version numbers if necessary.
[[build-tool-plugins-gradle-exclude-rules]]
=== Default exclude rules
Gradle handles "`exclude rules`" in a slightly different way to Maven which can cause
unexpected results when using the starter POMs. Specifically, exclusions declared on
a dependency will not be applied when the dependency can be reached through a different
path. For example, if a starter POM declares the following:
[source,xml,indent=0,subs="verbatim,attributes"]
----
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.5.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.5.RELEASE</version>
</dependency>
</dependencies>
----
The `commons-logging` jar will *not* be excluded by Gradle because it is pulled in
transitively via `spring-context` (`spring-context` -> `spring-core` -> `commons-logging`)
which does not have an `exclusion` element.
To ensure that correct exclusions are actually applied, the Spring Boot Gradle plugin will
automatically add exclusion rules. All exclusions defined in the
`spring-boot-dependencies` POM and implicit rules for the "`starter`" POMs will be added.
If you don't want exclusion rules automatically applied you can use the following
configuration:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
springBoot {
applyExcludeRules=false
}
----
To learn more about the capabilities of the Dependency Management Plugin, please refer to
its {dependency-management-plugin-documentation}[documentation].

View File

@@ -283,8 +283,7 @@ in your `application.properties`, e.g.
There's a blog on https://www.openshift.com/blogs/run-gradle-builds-on-openshift[running
Gradle in Openshift] on their website that will get you started with a gradle build to
run the app. A http://issues.gradle.org/browse/GRADLE-2871[bug in Gradle] currently
prevents you from using Gradle newer than 1.6.
run the app.

View File

@@ -702,21 +702,11 @@ property, e.g. for a simple webapp or service:
==== Use Tomcat 7 with Gradle
[[howto-use-tomcat-7-gradle]]
You can use a resolution strategy to change the versions of the Tomcat dependencies,
e.g. for a simple webapp or service:
You can change the Tomcat version by setting the `tomcat.version` property:
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
----
configurations.all {
resolutionStrategy {
eachDependency {
if (it.requested.group == 'org.apache.tomcat.embed') {
it.useVersion '7.0.59'
}
}
}
}
ext['tomcat.version'] = '7.0.59'
dependencies {
compile 'org.springframework.boot:spring-boot-starter-web'
}
@@ -775,21 +765,12 @@ webapp or service:
[[howto-use-jetty-8-gradle]]
==== Use Jetty 8 with Gradle
You can use a resolution strategy to change the version of the Jetty dependencies, e.g.
for a simple webapp or service:
You can set the `jetty.version` property and exclude the WebSocket dependency, e.g. for a
simple webapp or service:
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
----
configurations.all {
resolutionStrategy {
eachDependency {
if (it.requested.group == 'org.eclipse.jetty') {
it.useVersion '8.1.15.v20140411'
}
}
}
}
ext['jetty.version'] = '8.1.15.v20140411'
dependencies {
compile ('org.springframework.boot:spring-boot-starter-web') {
exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'

View File

@@ -27,6 +27,8 @@ Phillip Webb; Dave Syer; Josh Long; Stéphane Nicoll; Rob Winch; Andy Wilkinson;
:dc-spring-boot: {dc-root}/org/springframework/boot
:dc-spring-boot-autoconfigure: {dc-root}/org/springframework/boot/autoconfigure
:dc-spring-boot-actuator: {dc-root}/org/springframework/boot/actuate
:dependency-management-plugin: https://github.com/spring-gradle-plugins/dependency-management-plugin
:dependency-management-plugin-documentation: {dependency-management-plugin}/blob/master/README.md
:spring-boot-maven-plugin-site: http://docs.spring.io/spring-boot/docs/{spring-boot-docs-version}/maven-plugin
:spring-reference: http://docs.spring.io/spring/docs/{spring-docs-version}/spring-framework-reference/htmlsingle
:spring-security-reference: http://docs.spring.io/spring-security/site/docs/{spring-security-docs-version}/reference/htmlsingle

View File

@@ -153,11 +153,12 @@ Maven, there is no "`super parent`" to import to share some configuration.
}
----
The <<build-tool-plugins.adoc#build-tool-plugins-gradle-plugin, `spring-boot-gradle-plugin`>>
is also available and provides tasks to create executable jars and run projects from
source. It also adds a `ResolutionStrategy` that enables you to
<<build-tool-plugins-gradle-dependencies-without-versions, omit the version number
for "`blessed`" dependencies>>:
The <<build-tool-plugins.adoc#build-tool-plugins-gradle-plugin,
`spring-boot-gradle-plugin`>> is also available and provides tasks to create executable
jars and run projects from source. It also provides
<<build-tool-plugins-gradle-dependency-management, dependency management>> that, among
other capabilities, allows you to omit the version number for any dependencies that are
managed by Spring Boot:
[source,groovy,indent=0,subs="attributes"]
----