The testing support in the CLI has proven to be more trouble than
it's worth. Our recommendation is that, once an app gets to the stage
of requiring a test suite, it should be converted to a Maven or
Gradle project. This makes it easy to version, publish, deploy etc
using the vast ecosystems of the two build systems.
As part of this change, the dependency management for Spock has been
moved into spring-boot-parent, thereby making it "private". This
allows it to continue to manage the test-only Spock dependency in
spring-boot-test without also managing the version of Spring that is
used by a user's application.
Closes gh-9087
Fixes gh-9043
This works, and feels like the right thing to do, since there is no
guarantee that extensions won't in turn use ServiceLoader for things
that we haven't yet anticipated.
Fixes gh-6829. Cc @wilkinsona in case he has an opinion.
Previously, CLI extensions where installed into the CLI's lib
directory which meant that they were on the class path of the app
class loader. Following the change to an executable jar's packaging,
this meant that they could not see classes in the CLI and a
ClassNotFoundException would result.
This commit updates the CLI to install extensions into lib/ext and
load commands using a new ClassLoader that has all of the jars in
lib/ext on its class path and that uses the launch class loader as
its parent.
Closes gh-6615
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
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
Phillip Webb
Andy Wilkinson
Johnny Lim
Eddú Meléndez
Stephane Nicoll
dreis
Dave Syer
Henri Kerola
nagarajasr
Jakub Narloch