Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
This reverts commit b1c0a7cda4.
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
SpringApplicationLifecycle provides lifecycle operations on the current
Spring Boot application. It can be registered as an MBean of the platform
MBean server if a specific property is set. Besides, the JMX name can
also be customized via a property in case more than one Spring Boot
application is started in the same process.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
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
Update invoker configuration so that only folders with a pom.xml file
are invoked. This helps when switching between the 1.1.x and master
branches since empty folders left by git no longer fail the build.
The Maven plugin allows spring-boot:run to be configured so that
resources are loaded from their output location rather than from
src/main/resources. This commit adds an equivalent configuration
option to the Gradle plugin. To disable source resources from being
added to the classpath in place of those in the output location
the configure the bootRun tasks like this:
bootRun {
addResources = false
}
Closes gh-2431
By default, when building a project's jar its runtime dependencies
are not taken into account as they are not needed to successfully
compile the code that will be packaged in the jar. A side-effect of
this was that, if a project that was being repackaged had a runtime
dependency on another project, then the repackaged jar would not
include the jar of the project on which it has the runtime dependency
as the jar had not been built.
This commit updates Boot's repackage task to have a dependency on the
jar task of any project dependencies in the runtime configuration
thereby ensuring that those dependencies' jars will have been built
before the repackaging occurs.
Fixes gh-2344
Add deployment tests for Tomcat, TomEE and WildFly to ensure that
a basic Spring Boot application can be deployed to a traditional
Application server.
Since the deployment tests can be quite slow, they currently only
run in the "full" build profile.
Fixes gh-1736
Upgrade to latest versions of Tomcat and Jetty and to the latest Servlet
API whilst will remaining compatible with Tomcat 7 and Jetty 8.
Fixes gh-1832, gh-369
Previously, the Gradle plugin’s ProjectLibraries produced a new library
for every file dependency, even if the dependencies where on the same
file. This would lead to a repackaging failure due to multiple
libraries having the same name.
This commit updates ProjectLibraries to treat file dependencies on the
same file as a single library, thereby resolving the name clash.
Fixes gh-1646
The applicationDefaultJvmArgs property was added in Gradle 1.7. This
commit updates RunPluginFeatures to access the property defensively
so that the plugin can be used with Gradle 1.6.
Fixes gh-1511
Previously, ProjectLibraries only considered a configuration's
direct file dependencies. This meant that a transitive file
dependency that should have been pulled in via a project dependency
was not included in the repackaged jar's lib directory.
ProjectLibraries has been updated to walk down the tree of project
dependencies and create libraries for any file dependencies that
are found.
Fixes gh-1368
Updates to prevent the maven-invoker-plugin from downloading remote
snapshot jars. Possibly caused by the recent changes to the
spring-boot-dependencies POM.
See gh-1413
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Spring Buildmaster
Phillip Webb