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
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.
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.
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
Stephane Nicoll
Andy Wilkinson
Phillip Webb
Domingo Suarez Torres
David Turanski
David Liu
Phillip Webb
Mark Ingram
Stephane Nicoll
Shawn Clark
Dave Syer