Previously, BootZipCopyAction would put the next entry to the stream
and then, in the case of a stored entry, configure its size, CRC32
etc. This had the benefit of being able to copy the entry into the
zip once, capturing its bytes for the calculation of the CRC32 as it
was copied. Unfortunately, while this produced zip files that could
be read by the JVM, other zip tools failed. For example, Go's zip
support that's used by CloudFoundry could not unzip the archive.
This commit updates BootZipCopy action to completely configure the
entry before putting it to the stream. This has the downside of
copying the file twice (once for the CRC32 and once to actually write
it to the zip stream) but this appears to be unavoidable as we have to
produce archives that can be unzipped without problems on all
platforms.
Closes gh-8816
Previously, the properties that applied to the BuildInfo task itself
and those that would be written into the build-info.properties file
were all configured on BuildInfo directly. This lack of separation
could be confusing.
This commit rework BuildInfo to separate the task's own properties
from those that are written into the build-info.properties file.
The task has also been updated so that changes to a project's
properties made after the task has been configured are reflected in
the build info properties.
bootRun's main and jvmArgs properties use mainClassName and
applicationDefaultJvmArgs respectively by convention.
bootJar and bootWar's mainClass property uses mainClassName by
convention.
The current implementation is undocumented so it's not clear exactly
what it's intended to do. It also appears to overreach as, for
example, it affects every JavaExec task in a project.
We may need to reinstate something that's somewhat equivalent, but I'd
like to do that armed with more information about the intent of the
functionality and some specific problems that need to be solved.
Previously, the Spring Boot plugin would automatically apply the
dependency management plugin and import the spring-boot-dependencies
bom. This made it very difficult to use Spring Boot's plugin without
also using its dependency management. It also made it difficult to
see where the dependency management was coming from.
This commit updates the Spring Boot plugin so that it no longer
automatically applies the dependency management plugin. Instead, the
plugin now reacts to the dependency management plugin being applied
by importing the spring-boot-dependencies bom. Users that do not
wish to use Spring Boot's dependency management capabilities can now
do so by not applying the dependency management plugin.
Closes gh-3164
Previously, the BootRepackage task would take the output of a Jar
or War task and repackage it in a similar manner to Spring Boot's
Maven plugin. This caused several problems in Gradle including
broken up-to-date checks and a lack of configurability. See the issues
referenced below for full details.
This commit replaces BootRepackage with BootJar and BootWar
for building executable jars and wars respectively. BootJar extends
Gradle's standard Jar task and BootWar extends Gradle's standard War
task. This means that terms of configuration, the creation of
executable jars and wars is now as flexible as the creation of
standards jars and wars.
Closes gh-8167
Closes gh-8099
Closes gh-6846
Closes gh-5861
Closes gh-5393
Closes gh-5259
Closes gh-3931
Andy Wilkinson
Johnny Lim
Phillip Webb
Stephane Nicoll