Update the Maven plugin so that layered jars now use the regular "flat"
format. The layers.idx file now describes which layer each file should
be placed.
See gh-20813
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Create a dedicated layer that is used to hold the launcher support
classes. The layer sits between `dependencies` and
`snapshot-dependencies` so that the layer is sensible for both
SNAPSHOT and RELEASE versions of Spring Boot
Closes gh-20529
Simplify layer customization logic for both Maven and Gradle and
refactor some internals of the Gradle plugin.
Both Maven and Gradle now use a simpler customization format that
consists of `application`, `dependencies` and `layer order` sections.
The `application`, `dependencies` configurations support one or more
`into` blocks that are used to select content for a specific layer.
Closes gh-20526
This commit adds configuration to the Spring Boot Gradle plugin that
allows the names and contents of layers to be customized in the build
configuration.
Fixes gh-20296
Maven's war plugin does not support reproducible builds, resulting in
the entries in the war file not being written in a consistent order
from build to build.
Closes gh-20176
This commit adds an additional 'layers/configuration' property that can
be used to refer to a separate layers configuration file. This separate
file defines:
* The layers and their order of precedence,
* How libraries are handled using filters that match against the
coordinates of each library, and
* How classes are handled using filters that match against the location
of the entry
An XSD to validate the XML configuration file is available.
Closes gh-20295
Co-authored-by: Stephane Nicoll <snicoll@pivotal.io>
Pull functionality from `Repackager` into a new `Packager` base class
and develop a variant for Docker image creation. The new `ImagePackager`
class provides a general purpose way to construct jar entries without
being tied to an actual file. This will allow us to link it to a
buildpack and provide application content directly.
Closes gh-19834
Support an alternative fat jar format that is more amenable to Docker
image layers.
The new format arranges files in the following structure:
BOOT-INF/
layers/
<layer-name #1>
/classes
/lib
<layer-name #2>
/classes
/lib
The `BOOT-INF/layers.idx` file provides the names of the layers and the
order in which they should be added (starting with the least changed).
The `JarLauncher` class can load layered jars in both fat and exploded
forms.
Closes gh-19767
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Update the `Repackager` class so that an additional `classpath.idx` file
is written into the jar that provides the original order of the
classpath. The `JarLauncher` class now uses this file when running as
an exploded archive to ensure that the classpath order is the same as
when running from the far jar.
Closes gh-9128
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Previously, when RunProcess handled a SIGINT it would immediately
attempt to destroy the process that it had run. This created a race
condition between the SIGINT being handled by the child process
and RunProcess destroying the child. The exact behavior of destroy
is implementation dependent and it may result in forcible termination
of the process where shutdown hooks are not called. This is what
happens on Windows. The exit code in such a case is 1 which prevents
anything from waiting for the process to complete from detecting
that it ended as a result of a SIGINT, leaving it with no choice but
to report an error. This is what happens with mvn spring-boot:run
with a forked process on Windows and results in the build failing.
This commit updates RunProcess to allow the child process to handle
the SIGINT itself, waiting for up to five seconds for that to happen
before the process is then destroyed. Given this time, the child
process exits with 130 which RunMojo already handles correctly as
indicating that the process died due to SIGINT and the build completes
with success as a result.
Fixes gh-18936
Apply checkstyle rule to ensure that private and package private
classes do not have unnecessary public methods. Test classes have
also been unified as much as possible to use default scoped
inner-classes.
Closes gh-7316
Since the move to JUnit 5, a number of tests were failing on Windows.
The majority were failing due to open file handles preventing the
clean up of the tests' temporary directory. This commit addresses
these failures by updating the tests to close JarFiles, InputStreams,
OutputStreams etc.
A change has also been made to CachingOperationInvokerTests to make
a flakey test more robust. Due to System.currentTimeMillis() being
less precise on Windows than it is on *nix platforms, the test could
fail as it would not sleep for long enough for the TTL period to have
expired.
With JDK 8 being the baseline and JDK 7 not being supported anymore we
can get rid of the workaround for a JDK 7 bug in
ProcessBuilder.inheritIO on Windows machines.
Closes gh-12337
Previously, the order of the entries in a TestJarFile was determined
by the underlying file system rather than by the order in which
they were added. This could lead to unpredicatable ordering and
failures in tests that verify archive entry ordering.
This commit updates TestJarFile to add entries to the archive in
insertion order.
See gh-11695
See gh-11696
Previously, the Repackager would write entries in the following
order:
- Libraries that require unpacking
- Existing entries
- Application classes
- WEB-INF/lib jars in a war
- Libraries that do not require unpacking
- Loader classes
Libraries that require unpacking were written before existing entries
so that, when repackaging a war, an entry in WEB-INF/lib would not
get in first and prevent a library with same location from being
unpacked. However, this had the unwanted side-effect of changing
the classpath order when an entry requires unpacking.
This commit reworks the handling of existing entries and libraries
that require unpacking so that existing entries can be written first
while also marking any that match a library that requires unpacking
as requiring unpacking.
Additionally, loader classes are now written first. They are the
first classes in the jar that will be used so it seems to make sense
for them to appear first. This aligns Maven-based repackaging
with the Gradle plugin's behaviour and with the structure documented
in the reference documentation's "The Executable Jar Format" appendix.
The net result of the changes described above is that entries are
now written in the following order:
- Loader classes
- Existing entries
- Application classes
- WEB-INF/lib jars in a war marked for unpacking if needed
- Libraries
Closes gh-11695
Closes gh-11696
Move projects to better reflect the way that Spring Boot is released.
The following projects are under `spring-boot-project`:
- `spring-boot`
- `spring-boot-autoconfigure`
- `spring-boot-tools`
- `spring-boot-starters`
- `spring-boot-actuator`
- `spring-boot-actuator-autoconfigure`
- `spring-boot-test`
- `spring-boot-test-autoconfigure`
- `spring-boot-devtools`
- `spring-boot-cli`
- `spring-boot-docs`
See gh-9316
Phillip Webb
Andy Wilkinson
Madhura Bhave
dreis2211
Scott Frederick
Stephane Nicoll
zhangt2333
Wagner Macedo
Robert Thornton
igor-suhorukov
Andreas Gebhardt
Oliver B. Fischer
Johnny Lim
Dmytro Nosan
andrey.onufreyko