Spring/spring-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Provide separate documentation (API and reference) for Gradle plugin

Browse Source
This commit is contained in:
Andy Wilkinson
2017-03-14 20:51:23 +00:00
parent 47c0c3c0ef
commit 01166381a0
47 changed files with 2247 additions and 678 deletions
Download Patch File Download Diff File Expand all files Collapse all files

515
spring-boot-docs/src/main/asciidoc/build-tool-plugins.adoc
View File

@@ -164,516 +164,11 @@ 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 use the
dependency management provided by `spring-boot-dependencies`.
[[build-tool-plugins-including-the-gradle-plugin]]
=== Including the plugin
ifeval::["{spring-boot-repo}" == "release"]
To use the Spring Boot Gradle Plugin configure it using the `plugins` block:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
plugins {
id 'org.springframework.boot' version '{spring-boot-version}'
}
----
endif::[]
ifeval::["{spring-boot-repo}" != "release"]
To use the Spring Boot Gradle Plugin simply include a `buildscript` dependency and apply
the `spring-boot` plugin:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
buildscript {
repositories {
maven { url 'http://repo.spring.io/snapshot' }
maven { url 'http://repo.spring.io/milestone' }
}
dependencies {
classpath 'org.springframework.boot:spring-boot-gradle-plugin:{spring-boot-version}''
}
}
apply plugin: 'org.springframework.boot'
----
endif::[]
[[build-tool-plugins-gradle-dependency-management]]
=== Gradle dependency management
The `spring-boot` plugin automatically applies the
{dependency-management-plugin}/[Dependency Management Plugin] and configures it 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"]
----
dependencies {
compile("org.springframework.boot:spring-boot-starter-web")
compile("org.thymeleaf:thymeleaf-spring5")
compile("nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect")
}
----
NOTE: The version of the `spring-boot` gradle plugin that you declare determines the
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>>.
To learn more about the capabilities of the Dependency Management Plugin, please refer to
its {dependency-management-plugin-documentation}[documentation].
[[build-tool-plugins-gradle-packaging]]
=== Packaging executable jar and war files
Once the `spring-boot` plugin has been applied to your project it will automatically
attempt to rewrite archives to make them executable using the
<<build-tool-plugins-gradle-repackage-configuration,`bootRepackage` task>>. You
should configure your project to build a jar or war (as appropriate) in the usual way.
The main class that you want to launch can either be specified using a configuration
option, or by adding a `Main-Class` attribute to the manifest. If you don't specify a
main class the plugin will search for a class with a
`public static void main(String[] args)` method.
TIP: Check <<build-tool-plugins-gradle-repackage-configuration>> for a full list of
configuration options.
To build and run a project artifact, you can type the following:
[indent=0]
----
$ gradle build
$ java -jar build/libs/mymodule-0.0.1-SNAPSHOT.jar
----
To build a war file that is both executable and deployable into an external container,
you need to mark the embedded container dependencies as belonging to the war plugin's
`providedRuntime` configuration, e.g.:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
...
apply plugin: 'war'
war {
baseName = 'myapp'
version = '0.5.0'
}
repositories {
jcenter()
maven { url "http://repo.spring.io/libs-snapshot" }
}
dependencies {
compile("org.springframework.boot:spring-boot-starter-web")
providedRuntime("org.springframework.boot:spring-boot-starter-tomcat")
...
}
----
TIP: See the "`<<howto-create-a-deployable-war-file>>`" section for more details on
how to create a deployable war file.
[[build-tool-plugins-gradle-running-applications]]
=== Running a project in-place
To run a project in place without building a jar first you can use the "`bootRun`" task:
[indent=0]
----
$ gradle bootRun
----
If <<using-spring-boot.adoc#using-boot-devtools,`devtools`>> has been added to your project
it will automatically monitor your application for changes. Alternatively, you can also
run the application so that your static classpath resources (i.e. in `src/main/resources`
by default) are reloadable in the live application, which can be helpful at development
time.
[source,groovy,indent=0,subs="verbatim,attributes"]
----
bootRun {
addResources = true
}
----
Making static classpath resources reloadable means that `bootRun` does not use the output
of the `processResources` task, i.e., when invoked using `bootRun`, your application will
use the resources in their unprocessed form.
[[build-tool-plugins-gradle-global-configuration]]
=== Spring Boot plugin configuration
The gradle plugin automatically extends your build script DSL with a `springBoot` element
for global configuration of the Boot plugin. Set the appropriate properties as you would
with any other Gradle extension (see below for a list of configuration options):
[source,groovy,indent=0,subs="verbatim,attributes"]
----
springBoot {
backupSource = false
}
----
[[build-tool-plugins-gradle-repackage-configuration]]
=== Repackage configuration
The plugin adds a `bootRepackage` task which you can also configure directly, e.g.:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
bootRepackage {
mainClass = 'demo.Application'
}
----
The following configuration options are available:
[cols="2,4"]
|===
|Name |Description
|`enabled`
|Boolean flag to switch the repackager off (sometimes useful if you
want the other Boot features but not this one)
|`mainClass`
|The main class that should be run. If not specified, and you have applied the application
plugin, the `mainClassName` project property will be used. If the application plugin has
not been applied or no `mainClassName` has been specified, the archive will be searched
for a suitable class. "Suitable" means a unique class with a well-formed `main()` method
(if more than one is found the build will fail). If you have applied the application
plugin, the main class can also be specified via its "run" task (`main` property) and/or
its "startScripts" task (`mainClassName` property) as an alternative to using the
"springBoot" configuration.
|`classifier`
|A file name segment (before the extension) to add to the archive, so that the original is
preserved in its original location. Defaults to `null` in which case the archive is
repackaged in place. The default is convenient for many purposes, but if you want to use
the original jar as a dependency in another project you must use a classifier to define
the executable archive.
|`withJarTask`
|The name or value of the `Jar` task (defaults to all tasks of type `Jar`) which is used
to locate the archive to repackage.
|`customConfiguration`
|The name of the custom configuration which is used to populate the nested lib directory
(without specifying this you get all compile and runtime dependencies).
|`executable`
|Boolean flag to indicate if jar files are fully executable on Unix like operating
systems. Defaults to `false`.
|`embeddedLaunchScript`
|The embedded launch script to prepend to the front of the jar if it is fully executable.
If not specified the 'Spring Boot' default script will be used.
|`embeddedLaunchScriptProperties`
|Additional properties that to be expanded in the launch script. The default script
supports a `mode` property which can contain the values `auto`, `service` or `run`.
|`excludeDevtools`
|Boolean flag to indicate if the devtools jar should be excluded from the repackaged
archives. Defaults to `true`.
|===
[[build-tool-plugins-gradle-repackage-custom-configuration]]
=== Repackage with custom Gradle configuration
Sometimes it may be more appropriate to not package default dependencies resolved from
`compile`, `runtime` and `provided` scopes. If the created executable jar file
is intended to be run as it is, you need to have all dependencies nested inside it;
however, if the plan is to explode a jar file and run the main class manually, you may already
have some of the libraries available via `CLASSPATH`. This is a situation where
you can repackage your jar with a different set of dependencies.
Using a custom
configuration will automatically disable dependency resolving from
`compile`, `runtime` and `provided` scopes. Custom configuration can be either
defined globally (inside the `springBoot` section) or per task.
[source,groovy,indent=0,subs="verbatim,attributes"]
----
task clientJar(type: Jar) {
appendix = 'client'
from sourceSets.main.output
exclude('**/*Something*')
}
task clientBoot(type: BootRepackage, dependsOn: clientJar) {
withJarTask = clientJar
customConfiguration = "mycustomconfiguration"
}
----
In above example, we created a new `clientJar` Jar task to package a customized
file set from your compiled sources. Then we created a new `clientBoot`
BootRepackage task and instructed it to work with only `clientJar` task and
`mycustomconfiguration`.
[source,groovy,indent=0,subs="verbatim,attributes"]
----
configurations {
mycustomconfiguration.exclude group: 'log4j'
}
dependencies {
mycustomconfiguration configurations.runtime
}
----
The configuration that we are referring to in `BootRepackage` is a normal
{gradle-dsl}/org.gradle.api.artifacts.Configuration.html[Gradle
configuration]. In the above example we created a new configuration named
`mycustomconfiguration` instructing it to derive from a `runtime` and exclude the `log4j`
group. If the `clientBoot` task is executed, the repackaged boot jar will have all
dependencies from `runtime` but no `log4j` jars.
[[build-tool-plugins-gradle-configuration-options]]
==== Configuration options
The following configuration options are available:
[cols="2,4"]
|===
|Name |Description
|`mainClass`
|The main class that should be run by the executable archive.
|`providedConfiguration`
|The name of the provided configuration (defaults to `providedRuntime`).
|`backupSource`
|If the original source archive should be backed-up before being repackaged (defaults
to `true`).
|`customConfiguration`
|The name of the custom configuration.
|`layout`
|The type of archive, corresponding to how the dependencies are laid out inside
(defaults to a guess based on the archive type). See
<<build-tool-plugins-gradle-configuration-layouts,available layouts for more details>>.
|`layoutFactory`
|A layout factory that can be used if a custom layout is required. Alternative layouts
can be provided by 3rd parties. Layout factories are only used when `layout` is not
specified.
|`requiresUnpack`
|A list of dependencies (in the form "`groupId:artifactId`" that must be unpacked from
fat jars in order to run. Items are still packaged into the fat jar, but they will be
automatically unpacked when it runs.
|===
[[build-tool-plugins-gradle-configuration-layouts]]
==== Available layouts
The `layout` attribute configures the format of the archive and whether the bootstrap
loader should be included or not. The following layouts are available:
[cols="2,4,1"]
|===
|Name |Description |Executable
|`JAR`
|Regular executable
<<appendix-executable-jar-format.adoc#executable-jar-jar-file-structure,JAR layout>>.
|Yes
|`WAR`
|Executable
<<appendix-executable-jar-format.adoc#executable-jar-war-file-structure,WAR layout>>.
`provided` dependencies are placed in `WEB-INF/lib-provided` to avoid any clash when
the `war` is deployed in a servlet container.
|Yes
|`ZIP` (alias to `DIR`)
|Similar to `JAR` layout, using
<<appendix-executable-jar-format.adoc#executable-jar-property-launcher-features,`PropertiesLauncher`>>.
| Yes
|`MODULE`
|Bundle dependencies (excluding those with `provided` scope) and project resources.
|No
|`NONE`
|Bundle all dependencies and project resources.
|No
|===
[[build-tool-plugins-gradle-configuration-custom-repackager]]
==== Using a custom layout
If you have custom requirements for how to arrange the dependencies and loader classes
inside the repackaged jar, you can use a custom layout. Any library which defines one
or more `LayoutFactory` implementations can be added to the build script dependencies
and then the layout factory becomes available in the `springBoot` configuration.
For example:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:{spring-boot-version}")
classpath("com.example:custom-layout:1.0.0")
}
}
springBoot {
layoutFactory = new com.example.CustomLayoutFactory()
}
----
NOTE: If there is only one custom `LayoutFactory` on the build classpath and it is
listed in `META-INF/spring.factories` then it is unnecessary to explicitly set it in the
`springBoot` configuration. Layout factories are only used when no explicit `layout` is
specified.
[[build-tool-plugins-understanding-the-gradle-plugin]]
=== Understanding how the Gradle plugin works
When `spring-boot` is applied to your Gradle project a default task named `bootRepackage`
is created automatically. The `bootRepackage` task depends on Gradle `assemble` task, and
when executed, it tries to find all jar artifacts whose qualifier is empty (i.e. tests and
sources jars are automatically skipped).
Due to the fact that `bootRepackage` finds 'all' created jar artifacts, the order of
Gradle task execution is important. Most projects only create a single jar file, so
usually this is not an issue; however, if you are planning to create a more complex
project setup, with custom `Jar` and `BootRepackage` tasks, there are few tweaks to
consider.
If you are 'just' creating custom jar files from your project you can simply disable
default `jar` and `bootRepackage` tasks:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
jar.enabled = false
bootRepackage.enabled = false
----
Another option is to instruct the default `bootRepackage` task to only work with a
default `jar` task.
[source,groovy,indent=0,subs="verbatim,attributes"]
----
bootRepackage.withJarTask = jar
----
If you have a default project setup where the main jar file is created and repackaged,
'and' you still want to create additional custom jars, you can combine your custom
repackage tasks together and use `dependsOn` so that the `bootJars` task will run after
the default `bootRepackage` task is executed:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
task bootJars
bootJars.dependsOn = [clientBoot1,clientBoot2,clientBoot3]
build.dependsOn(bootJars)
----
All the above tweaks are usually used to avoid situations where an already created boot
jar is repackaged again. Repackaging an existing boot jar will not break anything, but
you may find that it includes unnecessary dependencies.
[[build-tool-plugins-gradle-publishing-artifacts-to-a-maven-repository]]
=== Publishing artifacts to a Maven repository using Gradle
If you are <<build-tool-plugins-gradle-dependencies-without-versions, declaring
dependencies without versions>> and you want to publish artifacts to a Maven repository
you will need to configure the Maven publication with details of Spring Boot's
dependency management. This can be achieved by configuring it to publish poms that
inherit from `spring-boot-starter-parent` or that import dependency management from
`spring-boot-dependencies`. The exact details of this configuration depend on how you're
using Gradle and how you're trying to publish the artifacts.
[[build-tool-plugins-gradle-publishing-artifacts-to-a-maven-repository-inherit]]
==== Configuring Gradle to produce a pom that inherits dependency management
The following is an example of configuring Gradle to generate a pom that inherits
from `spring-boot-starter-parent`. Please refer to the
{gradle-user-guide}/userguide.html[Gradle User Guide] for further information.
[source,groovy,indent=0,subs="verbatim,attributes"]
----
uploadArchives {
repositories {
mavenDeployer {
pom {
project {
parent {
groupId "org.springframework.boot"
artifactId "spring-boot-starter-parent"
version "{spring-boot-version}"
}
}
}
}
}
}
----
[[build-tool-plugins-gradle-publishing-artifacts-to-a-maven-repository-import]]
==== Configuring Gradle to produce a pom that imports dependency management
The following is an example of configuring Gradle to generate a pom that imports
the dependency management provided by `spring-boot-dependencies`. Please refer to the
http://www.gradle.org/docs/current/userguide/userguide.html[Gradle User Guide] for
further information.
[source,groovy,indent=0,subs="verbatim,attributes"]
----
uploadArchives {
repositories {
mavenDeployer {
pom {
project {
dependencyManagement {
dependencies {
dependency {
groupId "org.springframework.boot"
artifactId "spring-boot-dependencies"
version "{spring-boot-version}"
type "pom"
scope "import"
}
}
}
}
}
}
}
}
----
The {spring-boot-gradle-plugin}[Spring Boot Gradle Plugin] provides Spring Boot support
in Gradle, allowing you to package executable jar or war archives, run Spring Boot
applications and use the dependency management provided by `spring-boot-dependencies`.
It requires Gradle 3.4 or later. Please refer to the {spring-boot-gradle-plugin}[plugin's
documentation] to learn more.

105
spring-boot-docs/src/main/asciidoc/howto.adoc
View File

@@ -827,12 +827,12 @@ Example in Gradle:
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
----
configurations {
compile.exclude module: "spring-boot-starter-tomcat"
compile.exclude module: 'spring-boot-starter-tomcat'
}
dependencies {
compile("org.springframework.boot:spring-boot-starter-web:{spring-boot-version}")
compile("org.springframework.boot:spring-boot-starter-jetty:{spring-boot-version}")
compile 'org.springframework.boot:spring-boot-starter-web'
compile 'org.springframework.boot:spring-boot-starter-jetty'
// ...
}
----
@@ -881,12 +881,12 @@ Example in Gradle:
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
----
configurations {
compile.exclude module: "spring-boot-starter-tomcat"
compile.exclude module: 'spring-boot-starter-tomcat'
}
dependencies {
compile("org.springframework.boot:spring-boot-starter-web:{spring-boot-version}")
compile("org.springframework.boot:spring-boot-starter-undertow:{spring-boot-version}")
compile 'org.springframework.boot:spring-boot-starter-web'
compile 'org.springframework.boot:spring-boot-starter-undertow'
// ...
}
----
@@ -2355,9 +2355,11 @@ To configure IntelliJ IDEA correctly you can use the `idea` Gradle plugin:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
buildscript {
repositories { jcenter() }
repositories {
jcenter()
}
dependencies {
classpath "org.springframework.boot:spring-boot-gradle-plugin:{spring-boot-version}"
classpath 'org.springframework.boot:spring-boot-gradle-plugin:{spring-boot-version}'
classpath 'org.springframework:springloaded:1.2.6.RELEASE'
}
}
@@ -2424,7 +2426,7 @@ And to do the same with Gradle:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
springBoot {
springBoot {
buildInfo()
}
----
@@ -2502,16 +2504,7 @@ the artifact yourself instead of overriding the property.
WARNING: Each Spring Boot release is designed and tested against a specific set of
third-party dependencies. Overriding versions may cause compatibility issues.
To override dependency versions in Gradle, you can specify a version as shown below:
[source,groovy,indent=0]
----
ext['slf4j.version'] = '1.7.5'
----
For additional information, please refer to the
https://github.com/spring-gradle-plugins/dependency-management-plugin[Gradle Dependency
Management Plugin documentation].
[[howto-create-an-executable-jar-with-maven]]
=== Create an executable JAR with Maven
@@ -2593,15 +2586,6 @@ To configure a classifier of `exec` in Maven, the following configuration can be
</build>
----
And when using Gradle, the following configuration can be used:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
bootRepackage {
classifier = 'exec'
}
----
[[howto-extract-specific-libraries-when-an-executable-jar-runs]]
@@ -2637,15 +2621,6 @@ you would add the following configuration:
</build>
----
And to do that same with Gradle:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
springBoot {
requiresUnpack = ['org.jruby:jruby-complete']
}
----
[[howto-create-a-nonexecutable-jar]]
@@ -2689,29 +2664,6 @@ jar must be the main artifact and you can add a classified jar for the library:
</build>
----
In Gradle you can create a new JAR archive with standard task DSL features, and then have
the `bootRepackage` task depend on that one using its `withJarTask` property:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
jar {
baseName = 'spring-boot-sample-profile'
version = '0.0.0'
excludes = ['**/application.yml']
}
task('execJar', type:Jar, dependsOn: 'jar') {
baseName = 'spring-boot-sample-profile'
version = '0.0.0'
classifier = 'exec'
from sourceSets.main.output
}
bootRepackage {
withJarTask = tasks['execJar']
}
----
[[howto-remote-debug-maven-run]]
@@ -2723,34 +2675,6 @@ Check {spring-boot-maven-plugin-site}/examples/run-debug.html[this example] for
[[howto-remote-debug-gradle-run]]
=== Remote debug a Spring Boot application started with Gradle
To attach a remote debugger to a Spring Boot application started with Gradle you can use
the `jvmArgs` property of `bootRun` task or `--debug-jvm` command line option.
`build.gradle`:
[source,groovy,indent=0,subs="verbatim,attributes"]
----
bootRun {
jvmArgs "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
}
----
Command line:
[indent=0]
----
$ gradle bootRun --debug-jvm
----
Check {gradle-userguide}/application_plugin.html[Gradle Application Plugin] for more
details.
[[howto-build-an-executable-archive-with-ant]]
=== Build an executable archive from Ant without using spring-boot-antlib
To build with Ant you need to grab dependencies, compile and then create a jar or war
@@ -2894,10 +2818,9 @@ And if you're using Gradle:
}
----
NOTE: If you are using a version of Gradle that supports compile only dependencies (2.12
or later), you should continue to use `providedRuntime`. Among other limitations,
`compileOnly` dependencies are not on the test classpath so any web-based integration
tests will fail.
NOTE: `providedRuntime` is prefered to Gradle's `compileOnly` configuration as, among other
limitations, `compileOnly` dependencies are not on the test classpath so any web-based
integration tests will fail.
If you're using the <<build-tool-plugins.adoc#build-tool-plugins, Spring Boot build tools>>,
marking the embedded servlet container dependency as provided will produce an executable war

6
spring-boot-docs/src/main/asciidoc/index.adoc
View File

@@ -34,7 +34,8 @@ Phillip Webb; Dave Syer; Josh Long; Stéphane Nicoll; Rob Winch; Andy Wilkinson;
:dc-spring-boot-test-autoconfigure: {dc-root}/org/springframework/boot/test/autoconfigure
: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-boot-maven-plugin-site: http://docs.spring.io/spring-boot/docs/{spring-boot-docs-version}/maven-plugin/
:spring-boot-gradle-plugin: http://docs.spring.io/spring-boot/docs/{spring-boot-docs-version}/gradle-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
:spring-security-oauth2-reference: http://projects.spring.io/spring-security-oauth/docs/oauth2.html
@@ -50,8 +51,7 @@ Phillip Webb; Dave Syer; Josh Long; Stéphane Nicoll; Rob Winch; Andy Wilkinson;
:propdeps-plugin: https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin
:ant-manual: http://ant.apache.org/manual
:code-examples: ../java/org/springframework/boot
:gradle-user-guide: https://docs.gradle.org/2.14.1/userguide
:gradle-dsl: https://docs.gradle.org/2.14.1/dsl
:gradle-user-guide: https://docs.gradle.org/3.4.1/userguide
// ======================================================================================
include::documentation-overview.adoc[]

74
spring-boot-docs/src/main/asciidoc/using-spring-boot.adoc
View File

@@ -41,8 +41,8 @@ feel that's necessary.
The curated list contains all the spring modules that you can use with Spring Boot as
well as a refined list of third party libraries. The list is available as a standard
<<using-boot-maven-without-a-parent,Bills of Materials (`spring-boot-dependencies`)>>
and additional dedicated support for <<using-boot-maven-parent-pom,Maven>> and
<<build-tool-plugins-gradle-dependency-management,Gradle>> are available as well.
that can be used with both <<using-boot-maven-parent-pom,Maven>> and
{spring-boot-gradle-plugin}[Gradle].
WARNING: Each release of Spring Boot is associated with a base version of the Spring
Framework so we **highly** recommend you to not specify its version on your own.
@@ -194,70 +194,8 @@ the parent.
[[using-boot-gradle]]
=== Gradle
Gradle users can directly import '`starters`' in their `dependencies` section. Unlike
Maven, there is no "`super parent`" to import to share some configuration.
[source,groovy,indent=0,subs="attributes"]
----
repositories {
ifeval::["{spring-boot-repo}" != "release"]
maven { url "http://repo.spring.io/snapshot" }
maven { url "http://repo.spring.io/milestone" }
endif::[]
ifeval::["{spring-boot-repo}" == "release"]
jcenter()
endif::[]
}
dependencies {
compile("org.springframework.boot:spring-boot-starter-web:{spring-boot-version}")
}
----
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"]
----
ifeval::["{spring-boot-repo}" == "release"]
plugins {
id 'org.springframework.boot' version '{spring-boot-version}'
id 'java'
}
endif::[]
ifeval::["{spring-boot-repo}" != "release"]
buildscript {
repositories {
jcenter()
maven { url 'http://repo.spring.io/snapshot' }
maven { url 'http://repo.spring.io/milestone' }
}
dependencies {
classpath 'org.springframework.boot:spring-boot-gradle-plugin:{spring-boot-version}'
}
}
apply plugin: 'java'
apply plugin: 'org.springframework.boot'
endif::[]
repositories {
jcenter()
ifeval::["{spring-boot-repo}" != "release"]
maven { url 'http://repo.spring.io/snapshot' }
maven { url 'http://repo.spring.io/milestone' }
endif::[]
}
dependencies {
compile("org.springframework.boot:spring-boot-starter-web")
testCompile("org.springframework.boot:spring-boot-starter-test")
}
----
To learn about using Spring Boot with Gradle, please refer to the
{spring-boot-gradle-plugin}[documentation for Spring Boot's Gradle plugin].
@@ -704,8 +642,8 @@ You might also want to use the useful operating system environment variable:
[[using-boot-running-with-the-gradle-plugin]]
=== Using the Gradle plugin
The Spring Boot Gradle plugin also includes a `bootRun` task which can be used to run
your application in an exploded form. The `bootRun` task is added whenever you import
the `spring-boot-gradle-plugin`:
your application in an exploded form. The `bootRun` task is added whenever you apply the
the `org.springframework.boot` and `java` plugins:
[indent=0,subs="attributes"]
----