Create a new `JarFileWrapper` class so that we can wrap and existing
`JarFile` and offer a version that can be safely closed.
Prior to this commit, we provided wrapper functionality in the `JarFile`
class itself. Unfortunately, because we override `close` and also create
a lot of wrappers this caused memory issues when running on Java 11.
With Java 11 `java.util.zip.ZipFile` class uses `FinalizableResource`
for any implementation that overrides `close()`. This means that any
wrapper classes will not be garbage collected until the JVM finalizer
thread runs.
Closes gh-22991
This adds build caching and build scans.
The changes required disabling scans when using the maven invoker
plugin in order to not cause duplicate build scans when invoking other
maven builds. There is also an empty `.mvn` folder in the
spring-boot-starters project to prevent duplicate build scans as well
since there is no way to pass properties to the maven-javadoc-plugin.
The checkstyle plugin was causing a cache miss with the
`propertyExpansion` because it contains an absolute path. The absolute
path is now ignored and instead the files are added as inputs to the
checkstyle plugin. This only enables the local build cache. The remote
cache is not yet enabled.
On my local machine:
./mvnw clean install build times go from about 30 minutes to about 10 minutes.
./mvnw clean install -Pfull build times go from about 60 minutes to about 13 minutes.
See gh-22089
Previously, Spring Boot's modules published Gradle Module Metadata
(GMM) the declared a platform dependency on spring-boot-dependencies.
This provided versions for each module's own dependencies but also had
they unwanted side-effect of pulling in spring-boot-dependencies
constraints which would influence the version of other dependencies
declared in the same configuration. This was undesirable as users
should be able to opt in to this level of dependency management, either
by using the dependency management plugin or by using Gradle's built-in
support via a platform dependency on spring-boot-dependencies.
This commit reworks how Spring Boot's build uses
spring-boot-dependencies and spring-boot-parent to provide its own
dependency management. Configurations that aren't seen by consumers are
configured to extend a dependencyManagement configuration that has an
enforced platform dependency on spring-boot-parent. This enforces
spring-boot-parent's version constraints on Spring Boot's build without
making them visible to consumers. To ensure that the versions that
Spring Boot has been built against are visible to consumers, the
Maven publication that produces pom files and GMM for the published
modules is configured to use the resolved versions from the module's
runtime classpath.
Fixes gh-21911
Update `LaunchedURLClassLoader` so that packages defined from exploded
archive folders have manifest attributes applied to them. Prior to this
calling `package.getImplementationTitle()` would only return the a
manifiest attribute when running non-exploded.
The root cause of this issue is the way that `URLClassLoader` handles
the different URL types. For URLs that reference a jar the manifest is
available. For URLs that reference a folder it isn't. When running
exploded we use a URL that references to the `BOOT-INF/classes` folder
directly. To fix the issue we now attempt to detect when `definePackage`
is being called directly, and replace `null` entries with actual
manifest values.
Fixes gh-21705
Update `JarFile` so that `super.close()` is called early so that the
file is not left open. Since we re-implement `JarFile` methods to work
directly on the underlying `RandomAccessDataFile`, it should be safe
to close immediately.
Closes gh-21177
Update `JarFile` so that `super.close()` is called early so that the
file is not left open. Since we re-implement `JarFile` methods to work
directly on the underlying `RandomAccessDataFile`, it should be safe
to close immediately.
See gh-21126
Update `JarURLConnection` to ensure that when connections are opened
a new copy of the JarFile is provided.
Prior to this commit, a single `JarFile` instance was shared which meant
that it could be accidental closed if accessed via
`JarURLConnection.getJarFile()`. If the underlying jar file is closed
then it's possible for a `NoClassDefFoundError` to be thrown if running
on JDK 11 with an active `SecurityManager`.
Closes gh-17796
ExecutableArchiveLauncher.createClassLoader(Iterator) calls
createClassLoader(URL) method with 'super'. This means overriding
createClassLoader(URL) is not possible without also overriding
createClassLoader(Iterator). The switch to 'this' enables that.
See gh-20851
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>
