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
State is accumulating unnecessarily in AST tranformation instances.
We can fix the ones we have implemented so far just by using a
local variable and passing it into the methods where it is used.
All the methods are private so this change is safe in a point release.
Fixes gh-5283
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
It seems that the code for executing a groovy closure from the
OptionHandler is never executed and therefore not needed.
Removing the code gives the benefit that the Groovy-classes are not
needed if someone else wants to use the spring-boot-cli infrastructure to
run his own cli interface.
Closes gh-4411
Previously, MavenSettings used a FileProfileActivator with no
PathTransformer. If a settings.xml file contains a file-activated
profile this would result in an NPE within Maven. This was made worse
by the NPE not being included in the resulting failure message which
hampered diagnosis of the problem.
This commit updates MavenSettings to configure its FileProfileActivator
with a PathTransformer. It also improves the failure message that’s
created from any problems that are reported by Maven while determining
the active profiles to include a problem’s exception if it has one.
Closes gh-4826
Update exit code support to allow the ExitCodeGenerator interface to
be placed on an Exception. Any uncaught exception implementing the
interface and returning a non `0` status will now trigger a System.exit
with the code.
Fixes gh-4803
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
The CLI application advertises `-cp` support but it appears that only
`--cp` is really supported. The fix for gh-178 forgot to update the
call to `getParser().parse(...)`.
See gh-178
Spring Initalizr now bundles a wrapper script for the build system. While
that wrapper has the necessary execute flag in the zip archive, that flag
is lost as the zip abstraction does not honor those.
The init command now makes sure to restore the execute flag on `mvnw`
and `gradlew` if necessary.
Unfortunately, this can't be tested as the Windows build would fail to
assert that the executable flag has been propertly set.
Closes gh-4392
Phillip Webb
Vedran Pavic
Andy Wilkinson
Spring Buildmaster
Stephane Nicoll
Johnny Lim
Jakub Narloch
Dave Syer
Johannes Edmeier
mnhock
Kirill Vlasov
Matt Benson