Update jar `Handler` fallback logic to directly support Tomcat
'jar:war:file' URLs. This commit allows contents to be accessed without
the JDK needing to extracted the nested jar to the temporary folder.
Closes gh-24553
Update the jar `Handler` class to support a non-reflective fallback
mechanism when possible. The updated code attempts to capture a regular
jar URL before our handler is installed. It can then use that URL as
context when creating the a fallback URL. The JDK jar `Handler` will
be copied from the context URL to the fallback URL.
Without this commit, resolving new Tomcat URLs of the form
`jar:war:file:...` would result in an ugly "Illegal reflective access"
warning.
Fixes gh-18631
Prior to this commit, running the bootBuildImage Gradle task on a
project configured for war packaging would result in a jar file being
built and used in the image instead of the war file. With this commit
an error will be thrown from the plugin in this case.
Fixes gh-24521
This commit sets the pull policy to `IF_NOT_PRESENT` where possible
in integration tests for the Maven and Gradle plugins to reduce
the number of times the default Paketo builder and run images are
pulled from Docker Hub.
Fixes gh-24113
When a Configuration is copied, any before and after resolve actions
that are registered with its ResolvableDependencies are also copied
over. This means that, when a copied configuration is resolved the
resolution actions may be called on a ResolvableDependencies instances
that isn't the one to which they were added.
Previously, the above-described Gradle behaviour would result in
BootJar accessed the ResolvedConfiguration of a Configuration that may
not have yet been resolved. At best this would trigger Configuration
resolution and at worst it would fail. A failure could occur if the
configuration had been copied so that it could be made resolvable.
The afterResolve action would then try to access the
ResolvedConfiguration of the original Configuration. This would trigger
a resolution attempt that fails due to the original configuration being
marked as unresolvable.
This commit updates the afterResolve action in BootJar to check that
the ResolvableDependencies with which it is called matches the
ResolvableDependencies with which it was original registered. Only
when the two match, and therefore the configuration has actually been
resolved, does processing proceed.
Fixes gh-24072
A test case would fail to accurately capture the contents
of the layers.idx file unless the test project contained
at least one non-project snapshot dependency, which was only
true when the Spring Boot version was a snapshot.
See gh-23463
Stephane Nicoll
Valery Yatsynovich
Marten Deinum
Phillip Webb
Scott Frederick
Andy Wilkinson
Stephane Nicoll
izeye