Spring initializr now declares an improved metadata format (v2).
InitializrServiceMetadata has been updated to parse this format. Note
that the client could be further improved by using HAL generated links.
Closes gh-1953
Update the InitializrService so that a 'SpringBootCli' User-Agent header
is sent with each request. This should allow the server-side code to
gracefully evolve the JSON format if needed.
Fixes gh-1869
Upgrade to latest versions of Tomcat and Jetty and to the latest Servlet
API whilst will remaining compatible with Tomcat 7 and Jetty 8.
Fixes gh-1832, gh-369
Prior to this commit, specifying the --format and/or --build options
alongside --type did not use the explicit type as it should. This commit
ignores the --build and --format options if a type is explicitly set.
Fixes gh-1807
This commit moves the --output switch to a regular argument. This aligns
to other command, i.e. spring init my-project.zip would save the project
to "my-project.zip" in the current directory.
This commit also auto-detects the --extract option if the location ends
with a slash, i.e. spring init demo/ would extract the content of the
project in a demo directory that is local to the current directory.
Fixes gh-1802
This commit adds a new command to the CLI that allows to initialize a new
project from the command line. It uses the Spring initializr service to
actually generate the project.
The command offers two main operations:
1. Listing the capabilities of the service (--list or -l). This basically
dumps the defaults of a given service and the list of dependencies and
project types it supports
2. Generating a project. By default, http://start.spring.io is used and
its configured defaults are applied. Running spring init would therefore
have the same effect as clicking the 'generate project' on the UI without
entering any extra information. No file is overwritten by default.
The generation can be customized with the following options:
* --boot-version (-bv) Spring Boot version the project should use
* --dependencies (-d) comma separated list of dependencies to add to the
generated project
* --java-version (-jv) Java version to use
* --packaging (-p) the packaging for the project (jar, war)
* --target the url of the service to use
The actual type of the project can be defined in several ways:
1. Using the --type (-t) option that identifies a type that is supported
by the service
2. A combination of --build and/or --format that can be used to uniquely
identify matching these tags. Build represents the build system to use
(e.g. maven or gradle) while --format defines the format of the generated
project.
The project is saved on disk with the name provided by the server through
the Content-Disposition header, if any. It is possible to force it with
the --output option. It is possible to overwrite existing files by adding
the --force (-f) flag.
The --extract (-x) option allows to extract the project instead of saving
the zip archive. By default, the project is extracted in the current
working directory but it is possible to specify an alternate directory
using the --output option.
Fixes gh-1751
Prior to this commit LoggingSystem initialization would happen multiple
times. Once to configure "quiet" logging, and again to configure correct
settings once the Application was initialized. This could cause problems
if `logging.groovy` logback files were used.
The logging system is now only initialized once (when possible) by
following these steps:
- Standard logging initialization occurs via the actual logging
implementation used (e.g. logback will load a logback.xml file if it
exists)
- beforeInitization() is called to prevent early log output.
Implementations now either use a Filter or simply set the root logging
level.
- initialize() is called with an optional log configuration file (e.g
a custom logback.xml location) and an optional log output file (the
default is null indicating console only output).
The initialize() method will attempt to prevent double initialization
by checking if a standard configuration file exists. Double
initialization now only occurs in the following situations:
- The user has a standard configuration file (e.g. classpath:logback.xml)
but also specifies a logging.config property. Double initialization is
required since the specified configuration file supersedes the default.
- The user has a standard configuration file (e.g. classpath:logback.xml)
and specifies a logging.file property. Double initialization is
required since the standard configuration may use a ${LOG_FILE}
reference.
In addition this commit removes the `logging.console` option and now
assumes that logging either occurs only to console or to both the
console and a file. This restriction helps simplify the LoggingSystem
implementations. If file only logging is required a custom logback.xml
can be used.
Fixes gh-1091
See gh-1612, gh-1770
Previously, the CLI did not keep track of a dependency's users. This
meant that installing two extensions with a common dependency and
then unistalling one extension would break the other extension as the
common dependency would be deleted:
1. Install a that depends on c
2. Install b that depends on c
3. Uninstall b
4. a is now broken as c has been deleted
This commit updates the CLI to maintain a count for each artifact
that's installed into /lib. An artifact is now only deleted when the
count reaches zero.
As part of this change the code has been
extensively refactored to bring the structure into line with other CLI
commands and to improve testability.
Closes gh-1410
This commit avoids a script duplication: the integration test runs the
sample instead of a copy of it in the repro directory.
Also switched the sample from ActiveMQ to HornetQ as #323 revealed
some locking on CI. Hopefully that should fix it as HornetQ is non
persistent and can be embedded several times in the same VM.
Fixes gh-1456
This commit deprecates the proprietary EnableJmsMessaging annotation in
favour of the standard @EnableJms introduced as of Spring 4.1. This
commit also updates the sample and adds an integration test as the
feature was actually broken.
Fixes gh-1456
Previously, the CLI relied on Aether using the session's mirror
selector and authentication selector to customize the configured
repositories. These selectors are only used to configure what Aether
calls recessive repositories (repositories discovered when resolving
an artifact), rather than the explicitly configured repositories that
are typically used.
This commit updates AetherGrapeEngine to apply mirror and
authentication configuration to every added repository, bringing its
behaviour for these two settings into line with what it already does
for proxy configuration.
Fixes#1354
The lists are comma separated. In addition, user can add prefixes
"+" or "-", to signal that those values should be removed from the
default list, not added to a fresh one. E.g.
$ spring jar app.jar --include lib/*.jar,-static/** --exclude -**/*.jar
to include a jar file specifically, and make sure it is not excluded,
and additionally not include the static/** resources that would otherwise
be included in the defaults. As soon as "+" or "-" prefixes are detected
the default entries are all added (except the ones exlcuded with "-").
Fixes gh-1090
In the absence of a @GrabMetadata annotation,
DependencyResolutionContext provided no dependency management. This
was leading to incorrect dependency versions being pulled in. This
commit intializes the context with default dependency management that
will be replaced should @GrabMetadata be encountered.
Fixes#1021
We currently honour type, but ignore ext. Aether doesn't make a
distinction between the two so a Grab that specifies both type and ext
but with different values is considered to be an error.
Fixes#995
The main difference for now is the removal of the --nohup
(slightly hacky) option in TestCommand. Now a TestCommand
can signal to its caller that it wants to be hung up.
Fixes gh-975
Otherwise the ApplicationContext stays alive and if it's a
server app the JVM does not exit at the end of "spring test".
User can override with "spring test foo.groovy --nohup"
(which we have to do in our unit tests).
Up to now we have been treating the *first* class to be compiled
as the "main" application and adding @EnableAutoConfiguration. This
isn't always appropriate (e.g. if it's a test case), so now we
look for an appropriate annotation before falling back to the old
behaviour.
In addition ensures classes with a field of type Reactor trigger
the reactor auto imports.
See gh-969
JUnit tests can now be @SpringApplicationConfiguration
and @IntegrationTest without any explicit imports. Also
makes @RunWith(SpringJUnit4ClassRunner) optional.
Fixes gh-969
The issue was that the JreProxySelector was only applied
if the existing selector was null, but that hasn't been the case
since we added supporty for settings.xml. The strategy now is to
fallback to a JreProxySelector if the existing one is null
or not already a composite. Fixes gh-914.
Add support for a new annotation, @GrabMetadata, that can be used
to provide the coordinates of one or more properties files, such as
the one published by Spring IO Platform, as a source of dependency
metadata. For example:
@GrabMetadata("com.example:metadata:1.0.0")
The referenced properties files must be in the format
group:module=version.
Limitations:
- Only a single @GrabMetadata annotation is supported
- The referenced properties file must be accessible in one of the
default repositories, i.e. it cannot be accessed in a repository
that's added using @GrabResolver
Closes#814
Add a `versionManagement` gradle configuration which can be used to
provide alternative version meta-data. Primarily added so that the
Spring IO platform can provide version overrides without causing a
cyclic build dependency.
Fixes gh-750
Reverting arguments in assertEquals where constant was placed on
the "actual" place. Replacing assertEquals with assertFalse, assertTrue
and assertNull where applicable.
Fixes gh-735
This commit updates the CLI so that it will decrypt any encrypted
passwords in a user's Maven settings.xml file.
The code that performs the decrytion has a transitive dependency on
three types in Plexus' logging API. There are tens of different
artifacts containing this API available in Maven Central. Rather than
bloating the API with a dependency on a complete Plexus container,
which could perhaps be considered the primary source, a dependency on
a considerably smaller artifact has been introduced.
Closes#574
If the user adds a JAR file to the classpath in "spring jar -cp ..."
he expected it to end up in the classpath of the executable jar
(i.e. in the nested lib/ directory). Before this change it would
have gone in the root of the executable JAR, causing errors at runtime.
The fix is slightly awkward, since it assumes that any JAR in the
"roots" of the ResourceMatcher come from the classpath (which *is*
the case currently, but might not always be at least in principle).
Seems like a reasonable compromise given it's a quick change
and some tests have been included.
Fixes gh-565
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.
Stephane Nicoll
Phillip Webb
Andy Wilkinson
Phillip Webb
Dave Syer
Andy Wilkinson
sopov.ivan
Sebastien Deleuze