This commit improves the run goal to automatically fork the process when
devtools is present and log a warning when fork has been disabled via
configuration since devtools will not work on a non-forked process.
We don't want devtools to kick in for integration tests so the logic has
been placed in `RunMojo` requiring a couple of protected methods to
override.
Closes gh-5137
So far, one has to set the "fork" value to both the start and stop
goals. Since they have the same name, sharing them in a global
configuration element does the trick. However, the plugin also supports
auto-detection of the fork value according to other parameters:
typically if an agent or jvm arguments are set, forking will be
automatically enabled. This is a problem since the stop goal is not aware
of that.
This commit transmits the value in a property attached to the
`MavenProject`. That way, the stop goal can retrieve that value and
apply the same defaults. This has the side effect that specifying the
fork value isn't necessary anymore.
Closes gh-6747
Previously, configuring the build-info goal in a pom would result in
Eclipse reporting an error for the pom as it didn’t know if/when to
execute the build-info goal.
This commit adds lifecycle mapping metadata so that the goal is executed
on incremental builds. This ensures that the contents of the generated
file are kept up-to-date, reflecting the latest build time, etc.
Closes gh-6723
Previously, if mvn spring-boot:run with a forked JVM was killed with
CTRL+C, the run would be considered unsuccessful. This commits updates
the run mojo to consider a forked JVM that exists with 130 (the exit
code produced when exiting due to SIGINT which is what CTRL+C sends) to
be successful.
Closes gh-6498
The unpack location is (largely) an implementation detail and the
Repackage Mojo was the only place where it was explicity documented.
Rather than updating the outdated location, this commit removes it
entirely to avoid encouraging people to rely on the location.
Closes gh-6624
Where possible, code that previously synchronized on this (or on the
class in the case of static methods) has been updated to use an
internal monitor object instead. This allows the locking model that's
employed to be an implementation detail rather than part of the
class's API.
Classes that override a synchronized method continue to declare
the overriding method as synchronized. This ensures that locking
is consistent across the superclass and its subclass.
Closes gh-6262
Phillip Webb
Stephane Nicoll
Johnny Lim
Dave Syer
Plamen Totev
Spring Buildmaster
Andy Wilkinson