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]
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.
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, 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]
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.
- Look for JUnit test symbols, and add JUnit automatically
- Look for Spock test symbols, and add Spock automatically
- Based on what test libraries were used, invoke relevant embedded testers
and accumulate results
- Make it so that multiple testers can be invoked through a single 'test' command
- Print out total results and write out detailed trace errors in results.txt
- Update based on the new artifact resolution mechanism
Usually, use of @Grab requires you to specify a group, module, and
version when identifying a dependency. This can be done in two
different ways:
@Grab(group='alpha', module='bravo', version='1.0.0')
@Grab('alpha:bravo:1.0.0')
This commit allows users to only specify a module: the group is
inferred and the version is the one dictated by the boot CLI. Both
forms are supported:
@Grab(module='bravo')
@Grab('bravo')
Groovy's global AST transformations, which is how Grab is implemented,
do not support ordering and we need to augment the AST for the Grab
annotation before its processed by the Grab AST transformation. To
work around this, reflection is used to get hold of the compile
operations in the conversion phase, and a new AST transformation is
inserted immediately before the first AST transformation operation.
To allow a module's groupId and version to be resolved consistently,
META-INF/springcli.properties has been enhanced to include properties
for each module that we want to support in the following form:
<module>.groudId = <groudId>
<module>.version = <version>
<groupId> and <version> are taken from the Maven project's
dependencies and VPP, a Velocity-based pre-processor, is used to
automatically generate the enhanced properties file.
To prevent pollution of spring-boot-cli's class path with the
dependencies that are only required to populate springcli.properties,
a separate project, spring-boot-cli-properties, has been created.
spring-boot-cli depends upon this now project causing it to, via the
shade plug, include the properties file in its jar.
Previously DependencyCustomizer allow a dependency to be added by
specifying its full coordinates, i.e. a group ID, artifact ID, and
version. This commit updates DependencyCustomizer to only require
an artifact/module ID. The group ID and version are then resolved
using the same mechanism as the enhanced @Grab support.
[#56328644] [bs-312] Allow @Grab without version
- If RabbitTemplate is on the classpath, turn on autodetection.
- Create a RabbitTemplate, a Rabbit ConnectionFactory, and a RabbitAdmin is spring.rabbitmq.dynamic:true
- Enable some **spring.rabbitmq** properties like host, port, username, password, and dynamic
- Add tests to verify functionality
- Add Groovy CLI functionality. Base it on @EnableRabbitMessaging. Add spring-amqp to the path.
- Create rabbit.groovy test to prove it all works.
- Make Queue and TopicExchange top-level Spring beans in rabbit.groovy test script
* Add ability to detect spring-jms on the path and create a JmsTemplate with
ActiveMQConnectionFactory
* Create tests showing autoconfigured JmsTemplate with ActiveMQ, but prove it
backs off if a separate ConnectionFactory exists.
* Add support to spring-boot-cli to that it detects JmsTemplate, DefaultMessageListenerContainer,
or SimpleMessageListenerContainer, and turns on autoconfiguration as well as
add proper @Grab's and import statements.
* Write a jms.groovy test showing proper CLI support
Simplify ActiveMQ configuration
Update ActiveMQ to 5.7.0
* @EnableTransactionManagement triggers spring-tx imports
* Field or method of type JdbcTemplate or NamedParameterJdbcTemplate
of DataSource triggers spring-jdbc imports
A bug in ivy (tickled by maven leaving a pom
but no jar in the local repo) would make the
default Grapes ivy config fail (cannot grab...).
Phil's workaround now has a test case.
The Boot resolver didn't transfer enough of the settings
of the default ChainResolver. Adding a boolean flag was
enough to make the chatter die down for dependencies
that were unneeded.
[Fixes#55358344] [bs-291]
* Added src/main/content/bash_completion.d/spring
* Also made all commands alias to "--<self>" so
"--help" is a synonym for "help" (for instance). This
helps with the completion generation.
[Fixes#54827292]
