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
Spring Framework’s ParamterizedRowMapper has been deprecated since
3.1 and has been removed in 4.2. Spring Batch currently relies on
ParameterizedRowMapper, making it incompatible with 4.2. To allow us to
build successfully against 4.2, this commit ignores Spring Boot’s tests
that use Spring Batch’s JDBC support.
See gh-2575
Update the `init` command to support the latest meta-data format. Recent
Spring Initializr version also supports Spring Boot CLI now and generates
a textual service capabilities when requested. The command no longer
generates the capabilities of the service unless said service does not
support it.
Closes gh-2515
Previously, JarCommand removed all @GrabResolver annotations in an
AST transformation. This was being performed as custom resolver
configuration is not necessary in a jar as all of the dependencies are
available from the jar. Furthermore, leaving the annotations in place
caused a failure when the jar was run due to a missing Ivy dependency
that's required by Groovy's default GrapeEngine, GrapeIvy.
The removal of @GrabResolver annotations was being done before they
could be used by Groovy's GrabAnnotationTransformation to configure
the GrapeEngine's resolvers. This resulted in the annotations having
no effect such that a dependency that was only available from a
repository made available by @GrabResolver would fail to resolve if
it was not cached locally.
This commit updates the AST transformation to leave the @GrabResolver
annotations in place but to set their initClass attribute to false.
This allows the annotation to be used while the jar's being compiled,
but supresses the generation of the static initializer that adds the
custom resolver to the GrapeEngine when the compiled code's run via
java -jar.
Fixes gh-2330
Update JarCommand to only include nested libraries that are actually
zip files. Similar to commit 38585bf3 which introduced the same
functionality to the Repackager.
Fixes gh-2094
Partly back port changes from affb202e and 85c95744f to fix the usage
of JMS in the CLI. Restore the integration test using HornetQ and fix the
coordinates of the JMS API.
Fixes gh-2075
Previously, specifying a simple target name for a regular project would
store the (zip) archive in a file matching the target name. Only adding a
slash at the end of the name allows to extract it as a directory. It
turns out that such convention is not easy to catch and if a simple name
is provided on the command-line, the user probably wants to create a
directory with such a name with the content of the project.
Note that if a build file is required and the name does not have any
extension, we still store a file with the required name as auto-detecting
the extension to use is not that easy.
Fixes gh-2056
This commit adds support to the CLI for launching a custom
SpringApplication implementation. The class that is launched can be
configured using the spring.application.class.name System property
or the SPRING_APPLICATION_CLASS_NAME environment variable with the
former taking priority.
Closes gh-2030
In 1.1, the Groovy template support did not check that its configured
template location exists. A check was added in 1.2, however this
breaks CLI web applications that don't have the expected templates
location.
Rather than reintroducing 1.1's behaviour by removing the check, this
commit updates the CLI to set
spring.groovy.template.check-template-location to false by default.
This allows flow-blown applications to benefit from the check, while
allowing CLI apps to behave as they did in 1.1.
Closes gh-1959
Spring initializr now declares an improved metadata format (v2).
InitializrServiceMetadata has been updated to parse this format. Note
that the client could be further improved by using HAL generated links.
Closes gh-1953
Update the InitializrService so that a 'SpringBootCli' User-Agent header
is sent with each request. This should allow the server-side code to
gracefully evolve the JSON format if needed.
Fixes gh-1869
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
This commit updates the help command to also show some example(s) to
illustrate how the command can be used. The commit also defines useful
examples for the init command
Fixes gh-1809
Prior to this commit, specifying the --format and/or --build options
alongside --type did not use the explicit type as it should. This commit
ignores the --build and --format options if a type is explicitly set.
Fixes gh-1807
This commit moves the --output switch to a regular argument. This aligns
to other command, i.e. spring init my-project.zip would save the project
to "my-project.zip" in the current directory.
This commit also auto-detects the --extract option if the location ends
with a slash, i.e. spring init demo/ would extract the content of the
project in a demo directory that is local to the current directory.
Fixes gh-1802
This commit adds a new command to the CLI that allows to initialize a new
project from the command line. It uses the Spring initializr service to
actually generate the project.
The command offers two main operations:
1. Listing the capabilities of the service (--list or -l). This basically
dumps the defaults of a given service and the list of dependencies and
project types it supports
2. Generating a project. By default, http://start.spring.io is used and
its configured defaults are applied. Running spring init would therefore
have the same effect as clicking the 'generate project' on the UI without
entering any extra information. No file is overwritten by default.
The generation can be customized with the following options:
* --boot-version (-bv) Spring Boot version the project should use
* --dependencies (-d) comma separated list of dependencies to add to the
generated project
* --java-version (-jv) Java version to use
* --packaging (-p) the packaging for the project (jar, war)
* --target the url of the service to use
The actual type of the project can be defined in several ways:
1. Using the --type (-t) option that identifies a type that is supported
by the service
2. A combination of --build and/or --format that can be used to uniquely
identify matching these tags. Build represents the build system to use
(e.g. maven or gradle) while --format defines the format of the generated
project.
The project is saved on disk with the name provided by the server through
the Content-Disposition header, if any. It is possible to force it with
the --output option. It is possible to overwrite existing files by adding
the --force (-f) flag.
The --extract (-x) option allows to extract the project instead of saving
the zip archive. By default, the project is extracted in the current
working directory but it is possible to specify an alternate directory
using the --output option.
Fixes gh-1751
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Dave Syer
Spring Buildmaster
Graeme Rocher