Update the Maven and Gradle repackage tasks so that the embedded
startup script is no longer included by default. This change is
primarily due to the `cf` command line not currently accepting
the unusual jar format.
Fixes gh-3045
Do not rely on the packaging type to figure out what the extension of the
main artifact will be. So far, using `jar` and `war` packaging for `.jar`
and `.war` files worked by chance.
We know retrieve the actual extension as provided by Maven's
`ArtifactHandler`.
Fixes gh-2762
- Verify that isReady has been called
- When forking, use a random port for JMX
- Don’t wait for application termination as it introduces a race
condition and verifying that shutdown has been requested is
sufficient
See gh-2525
SpringApplicationLifecycle provides basic lifecycle operations on the
current Spring Boot application (that is checking if the application has
fully started and gracefully terminate the app). It can be registered as
an MBean of the platform MBean server if a specific property is set.
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
Some of the features of the launch.script were not exposed for users
to be able to control at runtime. It now accepts things like
PID_FOLDER and LOG_FOLDER as environment variables, and also adopts
a clear naming convention where only the inputs are UPPER_CASE.
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
Update JarWriter to set the entry timestamp for nested jars. The
timestamp is set to same time as the first (non directory) entry in
the nested jar.
This change should make it easier to created layered docker images.
Fixes gh-2807
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
The format is rather unusual.
The time is 16 bits: 5 bits for the hour, 6 bits for the minutes, and 5
bits for the seconds. 5 bits only allows 32 values (0-31) so the number
must be doubled, meaning that the time is only accurate to the nearest
two seconds. Also, the JDK rounds this down by subtracting one. The
doubling and rounding is performed by shifting one place to the left
and masking off the right-most bit respectively.
The date is 16 bits: 7 bits for the year, 4 bits for the month, and 5
bits for the day. The year is from 1980, i.e. the earliest date that
can be represented is 1980-01-01.
See http://mindprod.com/jgloss/zip.html for more details of the format.
Fixes gh-2826
Update the Maven and Gradle plugin to generate fully executable jar
files on Unix like machines. A launcher bash script is added to the
front of the jar file which handles execution.
The default execution script will either launch the application or
handle init.d service operations (start/stop/restart) depending on if
the application is executed directly, or via a symlink to init.d.
See gh-1117
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
Following the move to using the separate dependency management plugin
this test is no longer valid. It should have been removed as part of
2c3c62d7
See gh-2133
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
Previously repackaging of an archive was performed in three steps:
1. Write the manifest
2. Write entries from the source archive into the destination
3. Write any libraries into the destination if they’re not already there
This worked fine for jar files, but not for war files. In the war file
case the libraries are already in the source archive’s WEB-INF/lib
directory so they’re copied into the destination in step 2. This means
that step 3 largely becomes a no-op and, crucially, the UNPACK comment
is not applied to any libraries that require it.
This commit reorders steps 2 and 3 so that the libraries are copied into
the destination first (allowing the UNPACK comment to be written, if
required) and then any entries in the source are written into the
destination if they’re not already there.
Fixes gh-2588
Update ConfigurationMetadataAnnotationProcessor so that `prefix` is
only obtained when the annotation is not null. Also improve exception
message by including the element.
Parse a version using our version format or any version that complies
with Major.Minor.Patch. Also add a VersionRange utility that can
determine if a given version is withing that range.
Closes gh-2494
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
Phillip Webb
Eddú Meléndez
Stephane Nicoll
Andy Wilkinson
Dave Syer
Sylvère Richard
Spring Buildmaster