In Maven land, provided and system-scope dependencies are very similar,
the latter being an special kind that allows you to specify the path to
the artifact rather than using the repository to locate it.
Prior to this commit, the repackage goal of the maven plugin was
inconsistent as it would repackage provided-scope dependencies but would
ignore the system-scoped ones.
This commit adds an extra boolean flag, `includeSystemScope` to control
this behaviour. For backward compatibility reasons, its default value is
`false`.
Closes gh-2224
This commit improves the `InfoContributor` infrastructure as follows:
* `InfoEndpoint` no longer breaks its public API and returns a Map as
before
* `Info` is now immutable
* All properties of the build are now displayed. Since we control the
generation of that file, there is no longer a mode to restrict what's
shown
* Build info is now generated in `META-INF/build-info.properties` by
default
Closes gh-5734
Previously, a JVM that was forked by spring-boot:run could be orphaned
when the parent process (the Maven build) was terminated in an IDE. Note
that this doesn’t happen when spring-boot:run is invoked from a shell.
This commits add a shutdown hook that registered when RunMojo forks the
JVM. The shutdown hook attempts to kill the forked JVM’s RunProcess
rather than relying on the death of the parent process being sufficient
to also kill the child.
Closes gh-5815
The commit adds a new BuildInfo task that can be used to generate
a build.properties file, intended for inclusion in the Actuator's
info endpoint.
A default instance of the task can be configure using the plugin's
DSL:
springBoot {
buildInfo()
}
Additional properties can also be configured using the DSL:
springBoot {
buildInfo {
additionalProperties = [
'foo': 'bar'
]
}
}
When configured via the DSL, the Java plugin's classes task is
configured to depend on the build info task. Alternatively, if more
control is required, the task can be declared and configured manually:
task buildInfo(type: org.springframework.boot.gradle.buildinfo.BuildInfo) {
additionalProperties = [
'foo': 'bar'
]
}
classes {
dependsOn buildInfo
}
See gh-2559
This commit updates the Maven plugin to generate a
`META-INF/boot/build.properties` file with various build-specific
settings (group, artifact, name, version and build time). Additionally,
the plugin can be configured to write an arbitrary number of additional
properties.
A new `BuildProperties` bean is automatically exposed when such a file is
present. If that bean is present, an `InfoContributor` is automatically
created to expose that information under the `build` key.
As for the git contributor, it is possible to only display the core
settings or everything using the `management.info.build.mode` property.
See gh-2559
This commit allows to generate the packaged artifact only locally by
adding a new `attach` property. If `attach` is set to `false` explicitly,
only the main artifact is installed/deployed.
Closes gh-5258
When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
Generalize the `skip` property to start and stop goals so that one
can control if the Spring Boot app is starting via a configuration
property.
Note that this only controls the Spring Boot Maven plugin and the
failsafe maven plugin should be updated accordingly.
Closes gh-4922
Ensure that Collections.isEmpty() is used to check if there are no
elements in a collections. This is more explicit and can be faster than
calling .size().
Closes gh-4783
Replace all new-line characters in multi-line pom descriptions before
inserting into the launcher script. Prior to this commit the shell would
attempt to execut the extra lines, for example:
<description>
A multi-line pom description that could do something terrible:
rm -r foo
</description>
Closes gh-4703
Update the "INIT INFO section" of `launch.script` to include
`initInfoProvides`, `initInfoShortDescription` and `initInfoDescription`
property substitutions.
The Maven plugin has been updated to populate substitutions with
`${project.artifactId}`, `${project.name}` and `${project.description}`.
Fixes gh-4245
Flip the default value of `addResources` for both the Maven and Gradle
plugins. This effectively turns off static resources reloading and, more
importantly, the pruning of duplicate resources from the target
directory.
As devetools is our mainstram solution for such feature, the documantion
has been updated to reflect that.
Closes gh-4227
This commit adds a dedicated property to specify the active profiles to
use when running an application via the Maven plugin. This works also
on the command line using the `run.profiles` system property and is
consistently applied whether the process is forked or not.
Closes gh-4199
Add an `excludeDevtools` property to both the Maven and Gradle plugin
that removes `org.springframework.boot:spring-boot-devtools` (if
necessary) when repackaging the application.
Closes gh-3171
Stephane Nicoll
Andy Wilkinson
Tommy Ludwig
Spring Buildmaster
Johnny Lim
Jakub Narloch
Phillip Webb
Kirill Vlasov
Robert Thornton