Previously, DefaultRepositorySystemSessionAutoConfiguration would
read the local repository configuration from settings.xml, but did
not perform any property interpolation. This would leave placeholders
such as ${user.home} as-is and result in the use of the wrong
location. To address this, the code that reads settings.xml has been
updated to provide the current System properties as a property
interpolation source.
RepositoryConfigurationFactory configures the local repository as a
"remote" repository when the local repository location has been
overridden. This allows spring grab to copy dependencies from the
local repository into the grab output location (configured via the
grape.root system property) rather than having to download them again.
This logic did not consider the customization of the local repository
location via settings.xml so the dependencies would be downloaded again.
To address this, RepositoryConfigurationFactory has been updated to
attempt to use the location configured in settings.xml, before falling
back to the default location.
The logic that reads settings.xml has deliberately been duplicated. It
could have been extracted into a separate class, but this is only a
temporary measure until gh-3275 is tackled. Duplication was deemed
preferable to adding a new public class in 1.2.x that we’d then want to
remove in 1.3.
Closes gh-3274
When a Java 8 JVM is launched with -XX:MaxPermSize a warning message
is output indicating that the option will be ignored. This causes the
CLI tests that assert that no error output has been produced to fail.
This commit updates the CLI's integration test harness to remove
JAVA_OPTS from the environment of the CLI process. This prevents any
unwanted max perm size configuration from leaking into that
environment and breaking the build.
Update the `init` command to support the latest meta-data format. Recent
Spring Initializr version also supports Spring Boot CLI now and generates
a textual service capabilities when requested. The command no longer
generates the capabilities of the service unless said service does not
support it.
Closes gh-2515
Previously, JarCommand removed all @GrabResolver annotations in an
AST transformation. This was being performed as custom resolver
configuration is not necessary in a jar as all of the dependencies are
available from the jar. Furthermore, leaving the annotations in place
caused a failure when the jar was run due to a missing Ivy dependency
that's required by Groovy's default GrapeEngine, GrapeIvy.
The removal of @GrabResolver annotations was being done before they
could be used by Groovy's GrabAnnotationTransformation to configure
the GrapeEngine's resolvers. This resulted in the annotations having
no effect such that a dependency that was only available from a
repository made available by @GrabResolver would fail to resolve if
it was not cached locally.
This commit updates the AST transformation to leave the @GrabResolver
annotations in place but to set their initClass attribute to false.
This allows the annotation to be used while the jar's being compiled,
but supresses the generation of the static initializer that adds the
custom resolver to the GrapeEngine when the compiled code's run via
java -jar.
Fixes gh-2330
Update JarCommand to only include nested libraries that are actually
zip files. Similar to commit 38585bf3 which introduced the same
functionality to the Repackager.
Fixes gh-2094
Partly back port changes from affb202e and 85c95744f to fix the usage
of JMS in the CLI. Restore the integration test using HornetQ and fix the
coordinates of the JMS API.
Fixes gh-2075
Previously, specifying a simple target name for a regular project would
store the (zip) archive in a file matching the target name. Only adding a
slash at the end of the name allows to extract it as a directory. It
turns out that such convention is not easy to catch and if a simple name
is provided on the command-line, the user probably wants to create a
directory with such a name with the content of the project.
Note that if a build file is required and the name does not have any
extension, we still store a file with the required name as auto-detecting
the extension to use is not that easy.
Fixes gh-2056
This commit adds support to the CLI for launching a custom
SpringApplication implementation. The class that is launched can be
configured using the spring.application.class.name System property
or the SPRING_APPLICATION_CLASS_NAME environment variable with the
former taking priority.
Closes gh-2030
In 1.1, the Groovy template support did not check that its configured
template location exists. A check was added in 1.2, however this
breaks CLI web applications that don't have the expected templates
location.
Rather than reintroducing 1.1's behaviour by removing the check, this
commit updates the CLI to set
spring.groovy.template.check-template-location to false by default.
This allows flow-blown applications to benefit from the check, while
allowing CLI apps to behave as they did in 1.1.
Closes gh-1959
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
This commit updates the help command to also show some example(s) to
illustrate how the command can be used. The commit also defines useful
examples for the init command
Fixes gh-1809
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
