- 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
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
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
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
Previously, disabling forking was not possible if JVM arguments or an
agent are specified, even if the fork attribute is explicitly set to
`false`.
The fork attribute is now detected as it should and forking is disabled
when the fork attribute is set to false, even if JVM arguments or an
agent is either specified or discovered.
Fixes gh-2220
Add a 'module' layout for the repackager which includes all 'compile'
and 'runtime' scope dependencies and does not require a main class.
Fixes gh-1941
Prior to this commit, the repackage goal silently ignored the case of
two libraries having the same name and version but a different group.
As a result, the second library was overwriting the first one in the
repackaged jar.
This commit adds support for custom Library names and updates the
Maven and Gradle plugins so that the name includes the group ID
when there would otherwise be a duplicate.
Fixes gh-1475
This commit clarifies the role of the 'addResources' flag and makes
it explicit that any duplicate found in the target directory are
actually removed
Fixes gh-1479
This commit adds a 'skip' parameter to the 'repackage' goal that is
false by default. When this parameter is enabled, the repackage goal
does not run at all.
This can be used when repackaging should occur conditionally or
when a particular module in a hierarchy should not use this feature.
Fixes gh-1424
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
Add a Library class update the LibraryCallback interface and
implementations to use it. This change is in preparation for
an addition `unpack` flag that will be required to allow the
automatic unpacking of certain nested jars.
See gh-1070
Unify the versions used in integration tests launched by the
maven-invoker-plugin. Allows for already cached local copies to be
used, hopefully speeding up the build.
Previous to this commit, any groupId starting with one of the
configured exclude would be excluded as well. This potentially
leads to unintentional dependency filtering: for example the
GroupIdFilter with an exclusion of "org.springframework"
also removes "org.springframework.boot" dependencies.
Add MatchingGroupIdFilter that uses an exact match instead.
See #649
If an execution of the repackage goal is present in a project with
'pom' packaging, it is now skipped. This allows to configure the
plugin in the parent.
Fixes gh-867
The configuration within an execution is only applied when that
particular execution is invoked as part of the build. It is not
applied when the plugin is invoked on the command line (i.e.
mvn spring-boot:run).
This commit clarifies the situation so that users can safely copy/paste
those bits and get the expected behavior.
Fixes gh-875
The maven plugin now forks a new process when it starts a boot app. This
makes remote debugging of the app impossible without the ability to pass
extra JVM arguments.
This commit adds a "jvmArguments" attribute to the RunMojo that defines
additional JVM arguments to set on the forked process.
Fixes gh-848
This commit provides several options to exclude one or more
dependencies:
* excludes allows to specify an arbitrary number of exclude sub
element defining the groupId and artifactId of the dependency
to exclude
* excludedGroupIds defines the comma separated list of groupIds
to exclude
* excludeArtifactIds defines the comma separated list of artifactIds
to exclude
While any artifact can be excluded, this is designed to exclude
provided-scoped dependencies that should not be bundled in the
executable jar/war.
The outcome of java -jar myapp.jar should be consistent with the run
goal: these exclusions are therefore applied to the classpath that
the run goal computes to launch the application.
This commit also adds some integration tests and updates the
plugin's documentation
Fixes gh-649, gh-650 and gh-674
Commit e26e06d5dd broke the full build as the generated zip file for
the size is not generated. Actually, the site plugin has a jar goal that
is exactly meant for what we need to do.
This commit removes the use of the assembly plugin and invokes the
jar goal of the site plugin when the full profile is enabled.
Relates to #749
This commit adds the generated site for the maven plugin alongside
the developer guide and javadoc. The maven plugin is available in
the "/maven-plugin" context.
The advanced information described in the developer guide have
been migrated to the plugin site as most the information is taken
from the code itself, which avoids duplication.
Fixes#749
There were several problems to fix. 1) a bug in the
JDK (1.7 up to 7_60):
https://bugs.openjdk.java.net/browse/JDK-8023130
which we can work around by detecting buggy VMs and not trying
to use inheritIO. 2) File<->URL conversion is platform dependent
and we shouldn't make any assumptions. The problem in this case
was that file URLs contain a ":" so they can 't be added to a
path in UNIX, but on Windows you need the absolute path with the
colon. Solution: use Files on the classpath for spring-boot:run.
Hopefully also fixes gh-767
Before this change we were too aggressive in deleting duplicate resources
since directories might not have identical contents, and yet they were
being deleted anyway.
Fixes gh-614
When repackaging an archive, the files in the resulting lib directory
must be zip files. If they're not zip files, the resulting archive
may fail to run (#324).
The previous approach was to consider an artifact's type when deciding
whether or not it should be packaged. The type is a string and, while
there are a number of well-known values, it can essentially be anything.
This caused a problem with an artifact incorrectly being identified as
being unsuitable for inclusion (#489).
This commit changes the approach. Rather than looking at an artifact's
type, it looks at the first four bytes of the archive's file. Only if
these header bytes matche that of a zip file is the artifact included.
This is a better match for the requirement that all files in lib be zip
files.
Fixes#489
We had been making a special case for logback.xml anyway, so
extending that to simply deleting recursively all of
src/main/resources (or equivalent) from target/classes (or
equivalent) seems like it's perfectly justifiable.
Fixes gh-451
Requires Loaded 1.1.5 (or better).
For Maven you can just add springloaded to the dependencies of the
spring-boot plugin (and also set MAVEN_OPTS=-noverify).
For Gradle add springloaded to the build dependencies (-noverify
can be added by the plugin).
In both cases there is also support for adding an arbitrary java agent
via configuration. Samples are provided in
spring-boot-sample-[simple,web-ui].
The ApplicationPlugin is only added if there is no JavaExec task
already present, and additionally it computes its own man class if
none is provided. So "gradle run" and "gradle bootRun" look
superficially similar, but "bootRun" has extra options, including
the agent and Loaded support.
Fixes gh-251, gh-183
Update the `ArtifactsLibraries` used by the maven plugin to filter
based on artifact types. This prevent `.pom` files from accidentally
being packaged in `/libs` and ultimately resulting in 'Unable to find
ZIP central directory records' errors.
Fixes gh-324
Update the maven and gradle plugins to fail the build if a single
unique main class cannot be found. Additionally plugins will warn
if the search is taking too long.
Fixes gh-210
The Git plugin was primarily being used to provide version information
that Boot's maven plugin can add into the MANIFEST.MF of the uber-jars
that it creates under the Spring-Boot-Commit-Id attribute.
This commit removes the Git plugin from Boot's own projects, but
leaves it in the spring-boot-starter-parent for use by Spring
Boot-based applications.
The attribute in the uber-jars' MANIFEST.MF has been replaced with a
Spring-Boot-Version attribute. The value of this attribute is the
implementation version of Repackager class's package.
To use PropertiesLauncher instead of JarLauncher in an
executable JAR we have provided tooling support. In Maven
(using the starter parent to default some of the settings):
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>ZIP</layout>
</configuration>
</plugin>
in Gradle:
apply plugin: "spring-boot"
springBoot {
layout = 'ZIP'
}
}
[Fixes#58837492] [bs-330] Add tooling for PropertiesLauncher
PropertiesLauncher can now be used to run an executable jar, and by
default it will pick up nested archives in lib/ (where the Boot
tools puts them). User can provide loader.path (colon-separated)
to change the nested path.
[#58837492] [bs-330] Add tooling for PropertiesLauncher
Update RunMojo to include an @Execute annotation. Allows the use of
`mvn spring-boot:run` without having to compile/package first. Now a
command like `mvn clean spring-boot:run` works.
The phase for @Execute annotation is along the lines of what is used
for the `jetty:run` plugin.
Andy Wilkinson
Stephane Nicoll
Phillip Webb
Domingo Suarez Torres
David Turanski
David Liu
Phillip Webb
Mark Ingram
Stephane Nicoll
Shawn Clark
Dave Syer
Andy Wilkinson
Biju Kunjummen