This commit allows to specify a deprecation level to a manual metadata
entry. The purpose of that new attribute is to distinguish cases where
the property is still bound (default) from cases where the property no
longer exists and won't be bound.
This gives the opportunity to IDEs to still show the property as an
error and offer documentation and an action to rename it if a
replacement exists.
Closes gh-9074
Previously, if lombok was running before the configuration metadata
annotation processor, duplicated keys were created as both the
getter/setter and the special lombok handling applied.
This commit makes sure to be lenient by removing duplicate metadata
entries. This commit also makes sure to identify the getter of a
nested group if present. That way, the sourceMethod is set consistently
and avoid the creation of a duplicate group.
Closes gh-8886
This commit allows to specify a deprecation level to a manual metadata
entry. The purpose of that new attribute is to distinguish cases where
the property is still bound (default) from cases where the property no
longer exists and won't be bound.
This gives the opportunity to IDEs to still show the property as an
error and offer documentation and an action to rename it if a
replacement exists.
Closes gh-9074
This commit makes sure the integration tests use the same versions as
the one managed by `spring-boot-dependencies` (including Maven plugins).
Closes gh-8947
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
Update `PropertiesLauncher` so that classes can be loaded outside of
`BOOT-INF/classes`. You can use a subdirectory, or the root directory
of an external jar (but not the parent archive to avoid issues
with agents and awkward delegation models).
Fixes gh-8480
Closes gh-8486
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
Previously, jars (either top-level or nested) in Zip64 format were
treated as normal jar files. This would lead to a failure later on
when an attempt was made to read an entry from the file.
This commit updates the loader to fail fast when it encounters a
Zip64 jar file. Such files are identified by the number of entries
in the central directory end record being 0xFFFF.
Closes gh-8735
Previously, only IOExceptions were caught and wrapped in a new
IOException that included the name of the nested entry that was
being read.
Following this commit, any Exception is caught and wrapped so that the
problematic entry can be identified in more failure scenarios.
Closes gh-8711
Previously, each entry in loader.path could only refer to a standard
jar file. Refering to such a jar would add all of the classes in
the root of the jar to the class path.
This commit adds support for referencing a directory within a jar file
that contains one or more nested jars. For example:
$ java -jar -Dloader.path='jar:file:./lib.jar/!BOOT-INF/lib' my.jar
This will add all of the classes in all of that jars in the
BOOT-INF/lib directory of lib.jar to the class path.
See gh-8334
The main changes are:
- Switch to `loader.properties` instead of `application.properties`
- Search for `loader.properties` in `loader.home` as well as in
the classpath
- Placeholder replacements in MANIFEST.MF (using `loader.properties`
or system/env vars)
See gh-7221
Closes gh-8346
Previously, bootRepackage's excludeDevtools property would be
overridden by the springBoot extension's excludeDevtools property.
This prevented devtools from being included by configuring it on the
repackaging task.
This commit corrects the logic so that the setting on the repackaging
task takes priority. It also adds some tests to verify the behaviour.
Closes gh-8308
Johnny Lim
Andy Wilkinson
Phillip Webb
Stephane Nicoll
Madhura Bhave
Spring Buildmaster
Dave Syer
Huang YunKun
dreis