In fact the folder was already created if the app is running as
a different user, but not if running as the current user, so it
was just a question of moving one line out of an if block.
Fixes gh-5986
Update TypeUtils to guard against the use of older Java versions.
Both `Collection` and `Map` type lookups now fallback to generic free
versions of the classes.
Prior to this commit using `xmlbeans-maven-plugin` in combination with
Spring Boot's annotation processor could result in
`IllegalArgumentException: Incorrect number of type arguments`.
Fixes gh-6122
Previously, Maven repositories definition was specified in a profile that
is active by default. It means that as soon as any profile is enabled by
the user, said profile is no longer enabled. This has the nasty
consequences of having copy/paste in several places to make sure our own
profiles still have the proper repositories definition.
This commit creates a single "repositories" profile that is always active
unless a given property is explicitely specified. This allows to remove
the duplication and make things more consistent.
Some Gradle-specific repositories were also hard-coded in two modules
without any profile at all, meaning they were polluting the build of
anybody using it. While the impacted modules are gradle specific, that
repository has been shared in the new "repositories" profile as well.
Closes gh-6031
Previously, JarURLConnection didn't override getPermission(). This
meant that it required all permissions. This was at odds with the
Oracle JVM's concrete sun.net.www.protocol.jar.JarURLConnection which
overrides getPermission to return a FilePermission with the read
action for the path of the underlying jar.
This commit updates our JarURLConnection to align its behaviour with
sun.net.www.protocol.jar.JarURLConnection.
Closes gh-5411
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
Previously, arguments passed to the script were handled in one way
if a service was being started using start-stop-daemon and in another
way if start-stop-daemon wasn’t available or the application is being
launched in run mode. This meant that quoted arguments were only
handled correctly when the application was being started using
start-stop-daemon.
This commit updates the launch script so that argument handling is
the same across all three different way that the application can be
launched.
Closes gh-5942
Using a separate thread to call the application's main method is
unnecessary – the context class loader of the current thread can be
updated instead – and makes exception and exit code handling more
complicated than it needs to be.
This commit updates the Launcher so that it calls the main method
runner using the current (main) thread. As a result, any exception
that's thrown will be caught by the JVM and result in a non-zero exit
code being returned from the process.
Closes gh-5922
Previously, if the folder which contained the jar was a symlink the
launch script would use the symlinked folder's name when determining
the default identity.
This commit updates the launch script so that symlinks are resolved
and the canonical name of the folder which contains the jar is used
when determining the script's default identity. The behaviour when
APP_NAME has been set is unchanged.
Closes gh-5679
Closes gh-5733
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, if a void method with a single argument was named "set", the
annotation processor wrongly considered it was a setter candidate. This
commit updates the condition to ignore it.
Closes gh-5826
Previously, the Gradle plugin would include all of the dependencies
from both the compile and runtime configurations in the repackaged
jar. In the unlikely event that the compile and runtime configurations
contained different versions of the same dependency, this would lead
to both versions of the dependency being packaged in the jar file.
The runtime configuration extends the compile configuration so, in
normal circumstances, it will contain a superset of the compile
configuration's dependencies. In the situation described above where
the two configurations contain different versions of the same
dependency the runtime configuration will only contain whichever
version of the two dependencies has "won". By default, this will
be the dependency with the higher version.
This commit updates the Gradle plugin to only include the runtime
configuration's resolved dependencies during repackaging. As explained
above, the runtime configuration extends the compile configuration so
any compile dependencies will still be included, with the added
benefit that duplicate versions of the same dependency will have been
resolved to a single, preferred version.
Closes gh-5749
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
Update CentralDirectoryParser to reduce the number of objects created
when parsing the central directory. A single CentralDirectoryFileHeader
object is now reused as entries are parsed.
Fixes gh-5260
Previously, the CLI would always use the class loader to try to locate
a source file. This was contrary to the SourceOptions javadoc which
states that the class loader is “used to try and load files that are
not found in the local filesystem”. This provide to be problematic on
Windows when a fully-qualified source file was supplied. The driver
letter colon slash (e.g. c:/) at the start of the path is considered
invalid for a class path resource by URLClassPath.Loader resulting in an
IllegalArgumentException being thrown.
A workaround for this URLClassPath behaviour was added in a71c9b5d. It
was removed as part of reworking LaunchedURLClassLoader to use a
conventional delegation model in 87fe0b2a. It was then reinstated in
cc140b2c. This work around is undesirable as it causes
LaunchedURLClassLoader’s behaviour to diverge from URLClassLoader’s
behaviour (this is contrary to the comments in the test added in
a71c9b5d which incorrectly tests the two class loader with different
class paths. If the two class loaders are created with the same class
path then their behaviour is the same).
This commit updates SourceOptions to make its behaviour match its
javadoc so that a search of the class path is only performed if the
filename doesn’t exist on the filesystem. Furthermore, when running on
Windows, if the filename is an absolute path no further searching is
performed as the path cannot reliably be used to search the class path
due to the behaviour of URLClassPath.Loader when given a path that
is an absolute file path on Windows. This ensures that the user is
presented with an error message indicating that the file could not be
found.
Closes gh-5650
Previously, JarURLConnection would fail when created with a URL that
began with jar:file:// as the double-slash is not included in jarFile.getUrl().getFile().
This commit updates JarURLConnection to normalise the value return from
url.getFile() to remove a double-slash when present.
Fixes gh-5287
Closes gh-5289
Previously, JarLauncher considered any entry whose name began with
BOOT-INF/classes/ as being a nested entry. This was incorrect as it
meant that subdirectories of BOOT-INF/classes/ would be added to the
classpath rather than just BOOT-INF/classes/ itself.
This commit updates JarLauncher so that only directory entries with a
name equal to BOOT-INF/classes are used.
Closes gh-5610
Previously, if a JarFile was created from a directory nested inside
another jar file, it would look for the manifest in
pathFromRoot/META-INF/MANIFEST.MF. This is incorrect as, unlike a
JarFile created from a jar file, the archives are one and the same
so the manifests should be too.
This commit updates JarFile so that its aware of how it was created
(direct from a file, from a nested directory, from a nested jar). If
it was created from a file or from a nested jar, it uses its manifest.
If it was created from a nested directory, it uses the manifest of the
root archive.
Closes gh-5609
Previously, if loader.path directly specified a jar file that contained
nested archives (.zip or .jar), launching would fail unless those
nested archives were uncompressed. However, if loader.path specified a
directory that contained such a jar file the launch would succeed. This
was because the nested archives within the jar were ignored.
This commit updates PropertiesLauncher so that its behaviour in the
scenarios described above is consistent by not looking for archives
nested with a jar that’s be specified on loader.path. The javadoc for
loader.path has also been updated to make it clear that loader.path
can points to directories or jar files, bringing it into line with
the reference guide.
Closes gh-3701
Following changes to LaunchedURLClassLoader made in 87fe0b2a, it is
no longer necessary for the launcher to load MainMethodRunner via
reflection as both the app class loader that the launcher URL class
loader share the same MainMethodRunner class.
This commit takes advantage of this by updating Launcher to instantiate
MainMethodRunner directly rather than via reflection, removing one
source of possible exceptions in the launcher.
As the MainMethodRunner is now loaded directly and its class is shared
between the two class loaders, there’s no longer a need for it to
implement Runnable. This allows it to throw Exception from its run
method, rather than having to wrap any Exception in a RuntimeException.
Lastly, rather than catching any exception thrown from the launch,
Launcher and its subclasses have been updated to allow this exception
to be thrown from the main method. This allows the Exception to reach
the JVM, to be processed by our registered uncaught exception handler,
and to trigger the JVM’s standard processing for exiting due to a
failure. This removes the need for the Launcher itself to call
System.exit(1) and ensures that the exception is only output to the
console if it hasn’t been registered as a logged exception.
Closes gh-5358
Dave Syer
Phillip Webb
Stephane Nicoll
Andy Wilkinson
Tommy Ludwig
Christian Flamm
Spring Buildmaster
Johnny Lim
Jakub Narloch
Vladimir Tsanev
Christian Brunotte