Upgrading the JDK 9-based build to use JDK 9.0.4 has revealed that
Gradle 4.0.x doesn't work with it as it fails to parse the 9.0.4
version number.
This commit disables building the Gradle plugin on Java 9 (as we
had already done for Java 10) until we decide what to do
(see gh-12333).
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, 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
Andy Wilkinson
Phillip Webb
Eddú Meléndez
Vedran Pavic
Stephane Nicoll
danhyun
igor-suhorukov
Rui Figueira
Johnny Lim
dreis2211