A new command, jar, has been added to the CLI. The command can be
used to create a self-contained executable JAR file from a CLI app.
Basic usage is:
spring jar <jar-name> <source-files>
For example:
spring jar my-app.jar *.groovy
The resulting jar will contain the classes generated by compiling the
source files, all of the application's dependencies, and entries
on the application's classpath.
By default a CLI application has the current working directory on
its classpath. This can be overridden using the --classpath option.
Any file that is referenced directly by the classpath is always
included in the jar. Any file that is found a result of being
contained within a directory that is on the classpath is subject to
filtering to determine whether or not it should be included. The
default includes are public/**, static/**, resources/**,
META-INF/**, *. The default excludes are .*, repository/**, build/**,
target/**. To be included in the jar, a file must match one of the
includes and none of the excludes. The filters can be overridden using
the --include and --exclude options.
Closes#241
Update `GroovyCompiler` and `AetherGrapeEngineFactory` to use the
recently added `spring-boot-dependency-tools` in favor of loading
dependency information from a generated properties file.
--verbose seems to be only for CLI logging (so really only
for dependency resolution). --debug is interpreted by SpringApplication
but up to now has been extracted and deleted from the command line
by the CommandRunner. This change makes --debug set a System property
*and* pass it down to the application (if used with -- separator).
Fixes gh-266
Numerous updates to the Spring CLI, primarily for better embedded REPL
shell support:
* Refactor the CLI application to help separate concerts between the
main CLI and the embedded shell. Both the CLI and embedded shell now
delegate to a new `CommandRunner` to handle running commands. The
runner can be configured differently depending depending on need.
For example, the embedded shell adds the 'prompt' and 'clear'
commands.
* Most `Command` implementations have been moved to sub-packages so that
they can be co-located with the classes that they use.
* Option commands are now only used in the CLI, the embedded shell
does not user them and details have been removed from the Command
interface.
* The REPL shell has been significantly refactored to:
- Support CTRL-C to cancel the running process. This is supported
when running external commands and most internal commands.
- Fork a new JVM when running commands (primarily for CTRL-C support
but also for potential memory and classpath issues)
- Change the "continue" trigger from `<<` to `\`
- Support command completion of files
- Add ANSI color output
- Provide 'help' support for internal commands (such as 'clear')
- Remove the now redundant `stop` command
Fixes gh-227
In this commit we retain "init" as a command inside the ShellCommand
but not on the bash command line.
Seems to have an impact on performance so relevant to gh-212.
Replace references to 'files' throughout the code-base with 'sources'
following the rename of `FileOptions` to `SourceOptions`.
Also cleanup ResourceUtils a little
We check for existence of the sources and (as before) resolve multiple
resources on the classpath if a path is not a File. In addition supports
Spring pseudo-URL prefixes as well as normal URLs as source locations.
In addition sources can now be specified as a directory (searched
recursively by default), or a resource pattern (e.g. app/**/*.groovy).
Fixes gh-207
Recent changes to the repository configuration for @Grab
didn't update the tests which use the GroovyCompiler as
a standalone. Fixed that by using the
RepositoryConfigurationFactory.
The test passes locally, both in Eclipse and on the command line, but
fails on the CI server. Revert the addition of the test while I
hopefully figure out why.
This reverts commit 2e81b1d0d0.
Previously, Aether's configuration was largely hard-coded making it
impossible to configure a mirror, provide credentials for accessing
a repository, etc.
This commit adds support for configuring Aether via Maven's
settings.xml file. The support is optional and must be enabled by
grabbing spring-boot-maven-settings in an init script. The Aether
instance that's used when running the application will then be
configured using settings.xml. The settings file is expected to be
found in ${user.home}/.m2/settings.xml.
The configuration of the following items is currently supported:
- Offline
- Proxies
- Mirrors
- Server authentication
- Local repository location
If the support is not enabled, settings.xml does not exist, or
settings.xml does not configure certain things then sensible defaults
are applied.
When an init command is run, it may add entries to the classpath. This
commit adds a test that verifies that, if an entry that is added to
the classpath contains a CompilerAutoConfiguration file in
META-INF/services, then the CompilerAutoConfigurations declared in it
are found by subsequent ServiceLoader.load calls.
Users can declare or Command, OptionHandler classes in an init script
or they can use a DSL, e.g.
command("foo") { args -> println "Do stuff with ${args} array" }
or
command("foo") {
options { option "bar", "Help text for bar option" ithOptionArg() ofType Integer }
run { options -> println "Do stuff with ${options.valueOf('bar')}" }
}
InitCommand runs on creation of SpringCli so it can search for additional
Commands in updated classpath. Also added as interactive command in Shell
session.
Change SpringCli so that running without arguments no longer jumps into
the embedded REPL shell. This restores the ability to obtain quick usage
help by simply typing `spring` from the command prompt.
Windows users or developers that prefer the embedded shell can still
launch it using `spring shell`.
User can add (a single) beans{} DSL declaration (see GroovyBeanDefinitionReader
in Spring 4 for more detail) anywhere at the top level of an application source
file. It will be compiled to a closure and fed in to the application context
through a GroovyBeanDefinitionReader. Cool!
The example spring-boot-cli/samples/beans.groovy runs in an integration test
and passes (see SampleIntegrationTests).
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 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]
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]
Sebastien Deleuze
Phillip Webb
Andy Wilkinson
Dave Syer
Greg Turnquist
Roy Clarkson
Phillip Webb
Dave Syer