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
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 @GrabResolverCloses#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
Phillip Webb
Stephane Nicoll
Andy Wilkinson
Phillip Webb
Dave Syer
Andy Wilkinson
sopov.ivan
Sebastien Deleuze