This commit reworks BootRun so that it no longer subclasses JavaExec.
This provides Boot with greater control of how the executed JVM is
configured, including the possibility of using @Option to provide args
and JVM args via the command line (gh-1176). It also allows some usage
of convention mappings to be removed in favour of PropertyState and
Provider (gh-9891). For users who relied up the advanced (and rather
complex) configuration options provided by JavaExec, an escape hatch
is provided by allowing the JavaExecSpec that's used to execute the
JVM to be customized.
Closes gh-9884
In Java 9, a package may return null for its implementation version
even when the manifest attribute specifying the version is present
in the jar from which the package was loaded.
This commit updates DependencyManagementPluginAction to fall back to
accessing the jar and its manifest attributes directly when the
implementation version of its package is null.
Closes gh-10049
Previously, both Repackager and the Grade plugin used the JRE's
standard ZipOutputStream when creating a fat jar or war file. This
resulted in entry names that needed UTF-8 encoding to become
corrupted.
This commit updates both to use Commons Compress'
ZipArchiveOutputStream and to configure the stream's encoding and
each entry's Unix mode. This ensures that names are encoded using
UTF-8 and can be read back in correctly by common zip tools.
Closes gh-9405
Previously, Spring Boot's Gradle plugin provided custom software
components (bootJava and bootWeb) for publishing the artifacts created
by the standard bootJar and bootWar tasks respectively. Providing a
custom software component requires the usage of some of Gradle's
internal APIs and this has now proven to be more trouble than it is
worth.
This commit removes the custom software component and documents how
to publish the artifact created by a BootJar or BootWar task directly
instead.
Closes gh-9153
Usages has been removed in Gradle 4.0 and replaced with the use of
a new ObjectFactory API that can be used to create a Usage. This
commit uses reflection to access the ObjectFactory from the Project
and use it to create a Usage when an attempt to use Usages fails.
Closes gh-9364
Previously, the presence of a src/main/webapp/org directory would
cause the execution of BootWar to fail due to an attempt to write
a duplicate org/ entry to the zip output stream.
This commit updates BootZipCopyAction so that FileTreeElements that
match a directory entry created while writing the loader classes are
skipped.
Closes gh-8972
Windows seems unable to decide if the temp dir is in System32 or
system32 which breaks the comparison. This commit attempts to appease
the gods of case sensitity by reducing the portion of the path that we
check so that system32 vs System32 doesn't come into it.
See gh-8920
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.