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
In Gradle 3.3, when an API that will be removed in 4.0 is called, a
deprecation warning is output as part of the build. Users have noticed
his warning and, quite reasonably, complained about it. Unfortunately,
avoiding the warning requires the use of an API that was introduced in
Gradle 3.x which we can't use directly as we want to remain compatible
with Gradle 2.x.
This commit introduces the use of reflection to call
ProjectDependency.getTargetConfiguration() via reflection when it's
available (Gradle 3) and ProjectDependency.getProjectConfiguration()
when it's not (Gradle 2).
Closes gh-8154
Add an annotation processor that generates properties files for certain
auto-configuration class annotations. Currently attribute values from
@AutoConfigureOrder, @AutoConfigureBefore, @AutoConfigureAfter and
@ConditionalOnClass annotations are stored.
The properties file will allow optimizations to be added in the
`spring-boot-autoconfigure` project. Primarily by removing the need
to ASM parse as many `.class` files.
See gh-7573
Previously, AspectJ would find META-INF/aop.xml almost as soon as
the jar was launched, and before LaunchedURLClassLoader had been
created. This meant that AspectJ would attempt to load aspects listed
in META-INF/aop.xml but that were package in BOOT-INF/classes and,
therefore, could not be loaded.
This commit updates the Repackager so that a META-INF/aop.xml file
is moved into BOOT-INF/classes. This ensures that it isn't visible
to the app class loader so it won't be loaded to early. It will
now be loaded by LaunchedURLClassLoader which can also load the
compiled aspects that aop.xml references.
Closes gh-7587
Update Maven plugin to inform the BuildContext when changes are made to
the `build-info` file. Prior to this commit Eclipse could continually
trigger refreshes whenever "Refresh using native hooks or polling" was
enabled and the file was written to `src/main/resources`.
Closes gh-7741
This commit aligns the mapping from library to name to the default
behaviour of the `maven-war-plugin`. Previously, our plugin would use
the full version of the library (i.e. including build timestamp if there
is one), rather than using the `baseVersion` property.
Closes gh-7743
Create a parameter `STOP_WAIT_TIME` for the startup script
that configures the time in seconds to wait for a normal
shutdown. Because of #4941 we also send a shutdown half
way the countdown.
Fixes gh-7121
Expose the Required-Start and Require-Stop lines in the launch script
INIT INFO section as customizable embedded launch script properties.
This way one can express dependencies fron other init services by simply
changing the configuration in the build script.
Closes gh-7555
Previously, if the pathname of fully executable contained any space
characters, the launch script would fail to locate the jar file
This commit fixes this issue by quoting the jarfile.
Closes gh-7535
This commit uses standard files for libraries managed by the repackage
goal of the Maven plugin. Previously, only the name of the file was used
which could lead to duplicate libraries if the name of the target file
deviates from the default. This typically happens when the
`build.finalName` property is specified on a dependent module.
Note that the `maven-war-plugin` has an additional mechanism to customize
the file name structure of dependencies. This feature isn't supported by
the repackage goal so an explicit mention has been added in the
documentation.
Closes gh-7389
Allow support for custom Lyout implementations with both the Maven
and Gradle plugin. Implementations of `LayoutFactory` can now be
specified to allow customization of the layout. In addition a
layout may now implement `CustomLoaderLayout` if it wishes to
write custom loader classes.
See gh-7263
This commit makes sure that the `skip` command-line property can be used
for all goals of the maven plugin.
A dedicated sample for integration tests has also been added as this
change may confuse users, especially those who wish to skip a certain
goal and not the plugin execution altogether.
Closes gh-7313
Consider the following two URLs:
jar:file:/test.jar!/BOOT-INF/classes!/foo.txt
jar:file:/test.jar!/BOOT-INF/classes/foo.txt
They both reference the same foo.txt file in the BOOT-INF/classes
directory of test.jar, however the first URL does so via the
nested BOOT-INF/classes archive. Previously, this difference in the
URLs would lead to PathMatchingResourcePatternResolver returning two
resources for foo.txt when asked to find all resources matching the
pattern classpath*:/**/*.txt.
This commit updates our Handler that is used for jar: URLs to consider
the two URLs above to be equivalent such that url1 is equal to url2
and the two urls will produce the same hash code.
Closes gh-7449
Phillip Webb
Andy Wilkinson
Stephane Nicoll
dreis
Spring Buildmaster
Dave Syer
Eddú Meléndez
Johnny Lim
Madhura Bhave
Alessandro Falappa
Kazuki Shimizu
Gaurav Rawat
Arlo O'Keeffe
Lucas Saldanha
Pei-Tang Huang
Oscar Utbult
Hrishikesh Joshi
Christian Koops