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
Previously, if Boot's JarURLConnection pointed to the root of a nested
entry, e.g. /BOOT-INF/classes, a call to getInputStream() would throw
an IOException. This behavior is reasonable for a URL that points
to the root of a normal jar as the jar itself is on the class path
anyway. However, for a nested jar it meant that a call to
ClassLoader.getResources("") would not include URLs for any nested
jars and directories (/BOOT-INF/classes and jars in /BOOT-INF/lib).
This is due to some logic in URLClassPath.Loader.findResource that
verifies a URL by opening a connection and calling getInputStream().
The result of missing URLs for the root of nested jars and directories
is that classpath scanning that scans from the root (not a good idea
for performance reasons, but something that we should support) would
not find entries in /BOOT-INF/classes or in jars in /BOOT-INF/lib.
This commit updates our JarURLConnection so that it no longer throws
an IOException when asked for an InputStream for the root of a nested
entry (directory or jar).
Fixes gh-7003
Previously, the algorithm that computes the String representation of a
class reference and a property type was shared. This lead to generic
information for group's `type` and `sourceType` property.
This commit separates that logic in two: `getQualifiedName` is now
responsible to generate a fully qualified class name while the existing
`getType` is solely responsible to generate a type representation for the
property. Only the latter has generic information.
Closes gh-7236
This commit restores the logic in Handler that was changed when
d20ac56a was merged, while leaving the structural improvements intact.
In addition to a couple of changes where a typo meant the wrong
variable was being referenced, some logic branches now return false
rather than called super. This realigns our Handler's behaviour with
that of the JDK's.
Some more tests have also been added to try to catch the problems that
were introduced during the merge.
Closes gh-7021
Previously our handler didn't override parseURL or sameFile which
resulted in behaviour that differed from that of the JDK's handler.
Crucially, this would result in our JarURLConnection being passed
a spec that didn't contain a "!/". A knock-on effect of this was
that the connection would point to the root of the jar rather than
the intended entry.
Closes gh-7021
URL.getContent() is shorthand for URL.openConnection().getContent().
It creates an InputStream that isn't explicitly closed. This means
that a file handle remains open until the URLConnection is garbage
collected. This can lead to the process exceeding the limit for open
files.
Previously, LaunchedURLClassLoader was using getConent() when
proactively defining a package for a class that is about to be loaded.
getContent() was used to access nested jar files to check if they
contained the package and, if so, to retrieve the jar's manifest.
In place of using getContent(), this commit uses JarURLConnection's
getJarFile() method which provides access to the JarFile without the
unwanted side-effect of opening an input stream.
Closes gh-7180
Previously, a relative PID folder was not handled correctly when
running stop, status, or force_reload. This meant that a service
could be started when configured to use a relative pid file, but
then could not be stopped.
The PID folder should be treated as relative to the service's jar
file. This commit updates stop, status, and force_reload to push the
jar file's directory so that this is now the case for those three
commands.
Closes gh-7092
This commit makes sure that a meta-data group exposed via a deprecated
`@Bean` method is deprecated as well. This also works if the class
in which the bean method is defined is itself deprecated.
Closes gh-7100
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
This is an alternative to the fix made in 3b52909 which removed the
chown call entirely.
Prior to 3b52909, the ownership of $PID_FOLDER was always changed even
when its value was /var/run. This was problematic as it could prevent
other services from creating their pid folder or file.
When a sub-folder is used, changing its ownership so that it’s owned by
the user that will run the app is desirable as it limits access to the
folder. Rather than removing the chown call entirely, this commit
ensures that it only happens when a sub-folder is being used to hold the
pid file.
Closes gh-6532
Update the launch script so that it no longer changes ownership of the
PID_FOLDER.
Commit b24e736cfe had changed the chown
line from:
chown "$run_user" "$PID_FOLDER/${identity}"
to:
chown "$run_user" "$PID_FOLDER"
This meant that it was possible for the launch script to change
ownership of `/var/run` and prevent later processes from writing to
the folder.
Since PID_FOLDER is created before the chown statement, and that
the `checkPermissions` function runs to ensure that the PID file can
be written, it appears that the chown is not even required.
Fixes gh-6532
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, RandomAccessDataFile used a semaphore and acquired it
interruptibly. This meant that an interrupted thread was unable to
access the file. Notably, this would prevent LaunchedURLClassLoader from
loading classes or resources on an interrupted thread.
The previous commit (937f857) updates RandomAccessDataFile to acquire
the semaphore uninterruptibly. This commit adds a test to
LaunchedURLClassLoader to verify that it can now load a resource from
an interrupted thread.
Closes gh-6683
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
Phillip Webb
Andy Wilkinson
Spring Buildmaster
Eddú Meléndez
Stephane Nicoll
dreis
Johnny Lim
Madhura Bhave
Alessandro Falappa
Kazuki Shimizu
Gaurav Rawat
Arlo O'Keeffe
Lucas Saldanha
Pei-Tang Huang
Oscar Utbult
Hrishikesh Joshi
Dave Syer
Christian Koops
Plamen Totev
hengyunabc