It's super useful to get a reference to the current SpringCli
instance in the CommandFactory. Potentially implementations can
react to the properties of the Cli, or wrap it into something
more complex.
...supports the likely implementation of the REPL use
case that @jbrisbin has been working on.
Previously, the default classpath was empty. Now, in the absence of the
user providing a classpath via the -cp option, the default classpath
will be ".". If the user does specify a classpath, the classpath that's
used will be exactly what they have specified, i.e. "." will no longer
be on the classpath unless specified by the user.
The app sample integration test has been updated to verify that "." is
only the classpath by default.
Fixes#115
The JreProxySelector is used it to adjust the repositories
as they are added to the GrapeEngine. It looks at standard
System proeprties like http.proxyHost and http.proxyPort
and in addition consults standard JRE Authenticator features
for credentials (falling back to System properties
http.proxyUser and http.proxyPassword).
Fixes gh-136
Aether apparently doesn't use the java.net.* APIs for
TCP connections so it doesn't notice when a user sets
-Dhttp.Proxy*. To fix it is painful, and leads me to
suspect that actually we might want to parse a
settings.xml at some point (however unpalatable that
is).
For now I have added a Proxy to all RemoteRepository
instances that we create in the CLI if the user
has set -Dhttp.proxyHost (and/or -Dhttps.proxyHost for
a secure repository).
TODO: authentication. Is there a standard way to specify
that globally via system properties.
TODO: maybe use per-repository settings if provided
(e.g. in settings.xml).
The autoconfiguration transformations (and loads of grabs
of spring-boot snapshots) were making the grab command
tests run really slowly. Snapshots are particularly bad.
Fixed by adding a --autoconfigure=false option to the
compiler configuration and using it in that test.
Previously, run --local could be used to collect a script's
dependencies in ./repository. However, with this mechanism it wasn't
possible to collect the dependencies without running the application.
This commit adds a new command, grab, that can be used to collect
a script's dependencies in ./repository without having to run it.
run is configured with ./repository as a location in which it can find
its dependencies so that the previously collected dependencies
can be used when subsequently running the app.
As part of this work RunCommand and TestCommand have been refactored
to use common code for their common options:
--no-guess-imports
--no-guess-dependencies
--classpath
Previously, the declaration and handling of the options was duplicated
in the two classes. GrabCommand also has these three options and uses
the same common code.
Previously, the automatic addition of the group and version to a
@Grab annotation based on the module name would only work on standard
import statements. This commit adds support for this functionality
on wildcard imports, static imports and wildcard static imports.
All of the following are now supported:
@Grab('spring-core')
import org.springframework.util.Assert
@Grab('spring-core')
import org.springframework.util.*
@Grab('spring-core')
import static org.springframework.util.Assert.isTrue
@Grab('spring-core')
import static org.springframework.util.Assert.*
Refactor bash shell completion to move the majority of the logic into
the Java code. This commit also removes the need for the '--' prefix on
every command.
With the goal of making AetherGrapeEngine generally useful with Groovy,
this commit removes any Boot specifics from it. Specifically, there
is now only a single default repository: Maven Central. The
Boot-specific Spring milestone and snapshot repositories are now added
via @GrabResolver annotations that are added using an ASTTransformation.
As part of this change, AetherGrapeEngine has also been updated to store
its repositories using a LinkedHashSet, this ensures that the same
repository is not used more than once while maintaining their ordering.
Groovy's Grape allows a user to enable download reports using the
system property groovy.grape.report.downloads. This commit updates
AetherGrapeEngine to honour this property and produce a detailed
download report when the system property is set to true. In the
absence of the system property, or when it's set to a value other than
true, the existing summary report is still produced.
[bs-344]
[60145094]
@GrabExclude can now be used to exclude certain transitive dependencies.
In Aether (Maven), exclusions are applied to an individual dependency
rather than being global. In Grape, exclusions are global.
AetherGrapeEngine adheres to the Grape convention by applying every
exclusion create by @GrabExclude to every dependency, effectively making
them global.
@GrabResolver can now be used to add a repository to the list that is
used for dependency resolution. Any repository that is added via the
annotation will then be available for the lifetime of the
AetherGrapeEngine instance. In reality, this equates to the lifetime
of the Boot application. This is in keeping with the documented default
behaviour [1]: "By default, the grape subsystem is shared globally, so
added resolvers will become available for any subsequent grab calls".
[1] - http://groovy.codehaus.org/api/groovy/lang/GrabResolver.html
[bs-345]
[60145036]
b19f6bb238 updated the CLI so that it should be launched using Spring
Boot Loader's JarLauncher, however the spring and spring.bat shell
scripts were not updated so they still launched the CLI by using
SpringCli as the main class. This led to a NoClassDefFoundError
as none of the dependencies in the jar's /lib directory could be
found.
This commit updates the two shells scripts to use JarLauncher as the
main class.
By default it is on, but you can switch it
off (`-P '!integration'`) to ignore integration tests
and get a faster build.
.travis.yml uses this feature so that it doesn't keep
failing on a timeout.
Rework classloading for launched applications so that CLI classes and
dependencies are not visible. This change allows many of the previous
hacks and workarounds to be removed.
With the exception of the 'org.springframework.boot.groovy' package
and 'groovy-all' all user required depndencies are now pulled in
via @Grab annotations.
The updated classloading algorithm has enabled the following changes:
- AetherGrapeEngine is now back in the cli project and the
spring-boot-cli-grape project has been removed. The AetherGrapeEngine
has also been simplified.
- The TestCommand now launches a TestRunner (similar in design to the
SpringApplicationRunner) and report test failures directly using
the junit TextListener. Adding custom 'testers' source to the users
project is no longer required. The previous 'double compile' for
tests has also been removed.
- Utility classes have been removed in favor of using versions from
spring-core.
- The CLI jar is now packaged using the 'boot-loader' rather than using
the maven shade plugin.
This commit also applied minor polish refactoring to a number of
classes.
When running an application, --local can be used to collect the
application's dependencies in a local directory. Prior to
AetherGrapeEngine being introduced, using --local would result in the
dependencies being written to ./grapes. When AetherGrapeEngine was
introduced --local no longer had any effect.
This commit updates AetherGrapeEngine so that it honours --local,
writing its dependencies to ./repository. When --local is not specified
dependencies are written to ~/.m2/repository (the standard location
for the local Maven cache). As part of this change TestCommand has
been refactored so that it lazily initialises its GroovyCompiler. This
ensures that RunCommand has a chance to set the system property that
backs --local before AetherGrapeEngine is initialised and accesses the
property.
Fixes#99
3d714d301 allowed all integration tests to download snapshots and
milestones. The test for the integration sample, which depends upon a
milestone, no longer needs to be a special case.
Previously, GrapeEngineInstaller would only install its GrapeEngine
if an engine had not already been installed. As the Grape class stores
the engine in a static field, this meant that the engine would only be
installed once for the lifetime of Grape's classloader. This caused
an ordering issue in SampleIntegrationTests.
The test for the integration sample clears the
disableSpringSnapshotRepos system property to allow M1 of the
integration DSL to be resolved. However, this property is only
examined and honoured in AetherGrapeEngine's constructor. If another
test had run and had already created and installed an
AetherGrapeEngine, the new AetherGrapeEngine that allowed the use of
snapshot repositories would not be installed and the test would fail.
This commit updates GrapeEngineInstaller so that it always installs
its GrapeEngine, overwriting any previously installed engine.
Previously, the Ivy-based Grape engine used a system property,
disableSpringSnapshotRepos, to control whether or not Spring's
snapshot and milestone repositories were used for dependency
resolution. This commit adds the same capability to AetherGrapeEngine.
[#59489826]
@Grab allows a dependency to be declared, but for its transitive
dependencies to be excluded by setting transitive to false. This
commit enhances AetherGrapeEngine to honour this setting by using a
wildcard exclusion on any dependency so declared.
Spring Buildmaster
Phillip Webb
Dave Syer
Andy Wilkinson
Greg Turnquist