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.
Prior to this commit, the Aether-based GrapeEngine was loaded in the
same class loader as the rest of Boot. This led to Aether's and its
dependencies' types polluting the application's class path. Most
notably, this caused problems with logging as the logging framework
could be permaturely initialized.
This commit isolates AetherGrapeEngine, Aether and its dependencies
into a separate class loader. This is done by customizing the
packaging of the CLI's jar file with the internal directory housing
all of the types that will be loaded by the separate class loader.
Previously, @Grab annotations would use Ivy to download the
dependencies with some of Ivy's known limitations being worked around
by GrapeEngineCustomizer.
This commit adds a GrapeEngine implementation that uses Aether,
the dependency resolution 'engine' used by Maven and Grails. To ensure
consistent behaviour with a Maven build, the Aether-powered dependency
resolution uses the dependency management configuration from the
spring-boot-starter-parent pom file.
Previously, simple @Grab annotations only worked on classes. This commit
updates the simple @Grab support so that they can be used on anything
that can be annotated with @Grab.
The simplified @Grab support relies upon springcli.properties having
been generated. This commit adds an M2E lifecycle mapping for the
antrun plugin so that springcli.properties is generated as part of an
Eclipse build, thereby making it easier to run tests in Eclipse that
rely upon the simplified @Grab support.
Previously, LocalM2Resource used the pom's packaging configuration to
determine the suffix of the file that it should look for, e.g. if
the pom's packaging was jar, it would look for a file with a .jar
suffix in artifactExists(). This logic fails for artifacts with bundle
packaging as it would look for a .bundle file rather than a .jar file,
fail to find the file, and incorrectly report that the artifact does not
exist.
This commit updates LocalM2Resource to look for a file with a .jar
suffix when the packaging configuration in the pom is bundle.
Andy Wilkinson
Phillip Webb
Dave Syer
Greg Turnquist
Roy Clarkson