Previously, the JDK 10 build would fail as we build the plugin using
Gradle 4.0.x (the lowest version of Gradle that we support) and
Gradle 4.0.x doesn't work with Java 10.
Upgrading to Gradle 4.1, which appears to work with Java 10, was
considered but rejected for now as it introduces the risk that we
inadvertently use an API that's new in 4.1 and break our 4.0 support.
This commit goes for the extreme option and disables building the
Gradle Plugin when building with JDK.
See gh-12028
Previously, if the project's group, name, or version changed the
BuildInfo task would still be considered up-to-date as the values of
the project's properties were not reflected in the fields of the
BuildInfo instance.
This commit updates BuildInfo to copy the value of the project's
property to the corresponding BuildInfo field when the property is
read using its getter method on BuildInfo.
Closes gh-12266
Previously, working with a JarFile created a large amount of garbage
that was allocated on the thread local allocation buffer (TLAB).
The TLAB allocations made a significant contribution to GC pressure
and slowed down startup. This commit reduces the amount of garbage
by making a number of changes.
Reading from a RandomAccessDataFile has been reworked to avoid
creating new RandomAccessFile instances. A single RandomAccessFile
is now created for an entire jar file and it is used to read data from
anywhere in that jar file, including entries in nested jar files. To
ensure that reads remain thread-safe, a lock is taken on the
RandomAccessFile that is shared by all RandomAccessDataFile instances
that are provided access to (portions of) the same jar file.
Reading all of the bytes from a RandomAccessData has been reworked to
avoid the use of an InputStream that was created, used to read the
data, and then thrown away. In place of the InputStream-based
mechanism a method has been introduced that returns all of the
RandomAccessData as a byte[]. Building on this change, a method has
also been introduced to read a portion of a RandomAccessData as a
byte[]. This avoids the need to create a new RandomAccessData
subsection where the subsection was only used to read its entire
contents and then thrown away.
Decoding of an MS-DOS datetime has been reworked to use LocalDataTime
rather than GregorianCalendar. The former produces less garbage than
the latter.
Closes gh-12226
This commit changes invocations to immediately return the expression
instead of assigning it to a temporary variable. The method name should
be sufficient for callers to know exactly what will be returned.
Closes gh-12211
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
Previously, the ordering of the entries in an archive produced by
BootJar was different to the ordering of the entries in an archive
produced by BootWar. The latter placed application classes before
any nested jars, whereas the former was the other way around.
This commit updates BootJar to use the same ordering as BootWar and
adds tests to verify that the ordering is the following:
1. Loader classes
2. Application classes (BOOT-INF/classes or WEB-INF/classes)
3. Nested jars (BOOT-INF/lib or WEB-INF/lib)
4. Provided nested jars in a war (WEB-INF/lib-provided)
The tests also verify that the position of a library is not affected
by it requiring unpacking.
See gh-11695
See gh-11696
Stop running apply-plugin tests as part of the build since during a
release the version number will change and the jar will not be
available.
Fixes gh-11857
Update a couple of the `spring-boot-gradle-plugin` sample gradle flies
so that they include the running classpath. The additional lines are
contained within a tag which is ultimately filtered from the final
documentation.
Fixes gh-11857
