The `bootRun` gradle task or `spring-boot:run` maven goal can be used to
start a Spring Boot app with DevTools as long as forking is enabled. Add
an explicit note in the documentation to mention that.
Closes gh-3315
Add `spring.autoconfigure.exclude` to control the list of
auto-configuration classes to exclude via configuration. Merge the
exclusions defined on the `@EnableAutoConfiguration` or
`@SpringBooApplication` if any.
Closes gh-2435
Previously, the Spring Boot Gradle plugin would always apply the
application plugin to a project. It then piggy-backed on the application
plugin’s mainClassName and applicationDefaultJvmArgs properties for the
configuration of the bootRun task.
This commit updates the Spring Boot Gradle plugin so that it no longer
applies the application plugin. If the user applies the application
plugin then its configuration will be used, but it’s a no longer
requirement.
Users who do not need the application plugin, but who were using the
mainClassName or applicationDefaultJvmArgs properties will need to
change their builds as a result of this change as those properties will
no longer exist. As before, the mainClassName can be configured on the
springBoot extension:
springBoot {
mainClassName 'com.example.YourApplication'
}
The applicationDefaultJvmArgs property can be used, but it must now be
declared with the project's ext block. For example:
ext {
applicationDefaultJvmArgs = [ '-Dcom.example.property=true' ]
}
Closes gh-2679
These files are modified by Eclipse for some reason when you change files
like Thymeleaf HTML files. `META-INF/maven/**` has been added to the
default exclusion.
Closes gh-3295
Closes gh-3297
This reverts commit b1c0a7cda486e4f745b4233715efb8c0dc2814df.
The plugin publishing process has moved to a new plugin-based approach
that brings with it some significant limitations:
- There's no staging to allow the promotion of good release builds
- There's no easy way to upload an existing artifact
- There's no control over the published pom.
The risk brought by these limitations, particularly the first, are
too great so we will no be publishing the Boot plugin to the Portal
until they're resolved.
Changing the plugin's ID was a breaking change that would require
users to do some work when they upgrade to Boot 1.3. The ID of the
plugin was changed purely so that it met the Portal's requirements.
Given that the plugin will not be published to the Portal for the
foreseaable future there's no need for us to inflict a breaking change
on people when there will be no benefit.
See gh-1567
Initial update to the documentation to mention how a 3rd party starter
should be named. The current doc sends a completely inconsistent message
to what we actually intend.
See gh-2537
Gradle’s plugin portal requires each plugin’s ID to be in a namespace.
Our existing ID, spring-boot, does not meet this requirement. This
commit changes the plugin’s ID to org.springframework.boot.spring-boot.
Note that, as is recommended [1], the plugin’s ID does not include
“gradle”.
See gh-1567
[1] http://plugins.gradle.org/submit
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
Points to note for authors:
* Nesting "*" in `literals` does not behave like Markdown - you have to
escape the asterisk (e.g. `foo/\*`)
* Quote ligatures (why we had to use those I don't really know) are
different in asciidoctor 1.5 ('`foo`' instead of ``foo'')
Merge branch '1.1.x'
Conflicts:
spring-boot-docs/src/main/asciidoc/production-ready-features.adoc
spring-boot-docs/src/main/asciidoc/spring-boot-features.adoc
