Update `Repackager` to ensure that `getLayout` is called before we
backup the source file. This restores earlier behavior that some
custom `ModuleFactory` implementations were relying on.
Closes gh-22995
Prior to this commit, when the Maven plugin copied
spring-boot-loader.jar to a repackaged archive the timestamps of class
files were preserved but the timestamps of directories were not
preserved. This resulted in the directories having a current timestamp.
This commit copies the directory timestamps from spring-boot-loader.jar
to the repackaged archive and adds tests to verify the proper
behavior.
See gh-20927
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
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>
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.
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
Andy Wilkinson
Phillip Webb
dreis2211
Phillip Webb
Scott Frederick
Madhura Bhave
Andy Wilkinson
Stephane Nicoll
Robert Thornton
Johnny Lim