Previously, when writing a repackaged jar, an attempt to write all of
an entry's parent directories would always be made, irrespective of
whether or not the entry itself had already been written. This was
inefficient as, due to the way that the jar is written, once an entry
itself has been written, we know that all of its parent directories
will also have been written.
This commit updates the jar writer so that no attempt is made to
write parent directory entries if the entry itself has already been
written.
Fixes gh-29175
This commit adds configuration to the Maven and Gradle plugins to
allow specifying the names of build and launch cache volumes provided
to the CNB builder.
See gh-28292
Update `JarURLConnection` to use a single shared wrapper per
jar file rather than creating a new one each time. This update
should help to reduce GC pressure.
Fixes gh-28042
Update Maven and Gradle plugins to allow build info properties to be
excluded.
Prior to this commit, the `BuildPropertiesWriter` would fail with an
NPE if the group, artifact, name or version properties were `null`.
This was specifically problematic with the Gradle plugin, since its
DSL allows `null` properties which would either be passed to the writer
or, in the case of `artifact`, converted into a string value of
"unspecified".
See gh-27412
This commit adds configuration to the Maven and Gradle plugins to
allow specifying multiple tag to be created that refer to the built
image.
See gh-27613
Adding a label to the ephemeral builder image cloned from the base
builder image eliminates contention between builds that are run
concurrently. Without this label, concurrent builds could result in
a race condition in the Docker daemon if the ephemeral builder image
shared by builds was deleted by both builds at exactly the same time.
Fixes gh-27888
Previously, the optional configuration was added to the compile and
runtime classpaths of each source set and the the javadoc classpath
as well. This had a few disadvantages, the most notable of which is
that it meant that the configuration was ifrst resolved and then
the outcome of the resolution was added to the compile and runtime
classpaths. As a result, none of the attributes on the compile and
runtime classpaths were considered to influence variant selection.
This commit reworks the optional dependencies plugin so that the
compile and runtime classpaths of each source set are now configured
to extend from the optional configuration. This allows each
classpath configuration's attributes to influence the dependencies
that are selected from the optional configuration during resolution.
For example, when resolving the compile classpath, compile
dependencies (Usage.JAVA_API) will be selected and when resolving the
runtime classpath, runtime dependencies (Usage.JAVA_RUNTIME) will be
selected.
The above-described change means that runtime dependencies of an
optional dependencies will no longer leak into the compile classpath.
As a result of this, our Gradle plugin's test infrastructure has
been updated so that it no longer references runtime dependencies of
the Kotlin Gradle plugin at compile time.
Closes gh-27965
Previously, a Zip64 jar file was identified by the number of entries
in the central directory being 0xFFFF. This value indicates that
there the number of entries is too big for the 2-byte field. However,
a jar may be in Zip64 format due to it exceeding the Zip format's
maximum size rather than its maximum number of entries so this field
cannot be used as a reliable indicator. The Zip specification doesn't
require any of the fields of the end of central directory record to
have a value of 0xFFFF (2-byte fields) or 0xFFFFFFFF (4-byte fields)
when using Zip64 format so we need to take a different approach.
Additionally, a number of places in the code assumed that an entry's
offset would always be available from the central directory file
header directly. This assumption did not hold true when the jar was
a Zip64 archive due to its size as the offset's value would be
0xFFFFFFF indicating that it should be read from the Zip64 extended
information field within the header's extra field instead.
This commit updates the Zip64 detection to look for the Zip64 end of
central directory locator instead. If present, it begins 20 bytes
before the beginning of the end of central directory record. Its
first four bytes are always 0x07064b50. The code that reads the
local header offset has also been updated to refer to the Zip64
extended information field when the offset is too large to fit in
the 4-byte field in the central directory file header. To allow
greater-than-4-byte offsets to be handled, a number of fields,
method parameters, and local variables have had their type changed
from an int to a long.
Fixes gh-27822
Andy Wilkinson
izeye
Stephane Nicoll
Phillip Webb
Scott Frederick
Leo Li
slowjoe007
Julian Liebig
Vedran Pavic
Vincent Ricard
Rafael Ceccone
dreis2211