Commit Graph

413 Commits (cef02ae4b395346a9a91704a8599eb3493678bb8)

Author SHA1 Message Date
Phillip Webb a57a88f5cf Move master to 1.3.0.BUILD-SNAPSHOT 10 years ago
Spring Buildmaster 8f0ad02237 Next development version 10 years ago
Phillip Webb 56e31a8c6b Polish 10 years ago
Stephane Nicoll 9d0e50c6ac Support of spring initializr meta-data v2.1
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
10 years ago
Andy Wilkinson 54e90c03fc Polish the javadoc in spring-boot-cli
Add missing @param and @return elements
10 years ago
Phillip Webb 072f873f34 Polish 10 years ago
Stephane Nicoll 4bee1b0e1b Fix wrong help page for archive detection logic
Fixes gh-2355
10 years ago
Andy Wilkinson 16cb44f890 Merge branch '1.1.x' 10 years ago
Andy Wilkinson 376de01636 Don't remove @GrabResolver in JarCommand, disable initClass instead
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
10 years ago
Spring Buildmaster 60725cd8bd Next development version 10 years ago
Spring Buildmaster 63e6a25097 Next development version 10 years ago
Spring Buildmaster 1a788c1741 Next development version 10 years ago
Phillip Webb a8ae4d1a3f Only include zip files when using `spring jar`
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
10 years ago
Phillip Webb 3523bca79b Polish 10 years ago
Phillip Webb d3ccdc6319 Polish 10 years ago
Stephane Nicoll 9b598b49c2 Fix JMS support in the CLI
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
10 years ago
Phillip Webb 064fee38b1 Formatting 10 years ago
Stephane Nicoll 8efdffbc0e Smarter output detection for generated projects
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
10 years ago
Stephane Nicoll 61223e709c Fix error message 10 years ago
Phillip Webb 447c9ff204 Polish 10 years ago
Graeme Rocher dbcbebca4a Propagate exception / test failures so that the correct status code is returned.
Fixes gh-2048 and fixes gh-2051
10 years ago
Andy Wilkinson 8520554eb2 Allow the SpringApplication class used by the CLI to be configured
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
10 years ago
Phillip Webb 2a8579026f Polish 10 years ago
Andy Wilkinson 0e2300cf85 Disable check of Groovy template location by default for CLI apps
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
10 years ago
Phillip Webb c34cfb27a3 Polish 10 years ago
Stephane Nicoll 8f488bd019 Update init to new metadata format
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
10 years ago
Spring Buildmaster 46b7738334 Next development version 10 years ago
Phillip Webb 4fa8a94dd4 Update to latest Maven plugins
Fixes gh-1899
10 years ago
Phillip Webb 6027b2405c Add 'User-Agent' header to CLI REST calls
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
10 years ago
Phillip Webb e76a571dd3 Add @SpringBootApplication annotation
Add a new @SpringBootApplication which is equivalent to @Configuration,
@EnableAutoConfiguration and @ComponentScan.

See gh-1842
10 years ago
Phillip Webb b6bacd5e8a Upgrade to Servlet 3.1, Tomcat 8 and Jetty 9
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
10 years ago
Phillip Webb a973fd41f4 Polish 10 years ago
Stephane Nicoll 0061f237b8 Add examples to the CLI
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
10 years ago
Stephane Nicoll 6a18ece6a2 Explicit type takes precedence over build and format
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
10 years ago
Stephane Nicoll 2e07f003c9 Init command takes the output as last argument
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
10 years ago
Stephane Nicoll 96198e2999 polishing 10 years ago
Phillip Webb aa2e32a041 Restore CLI startup performance
Change InitializrService to use a late binding CloseableHttpClient
since the calling `HttpClientBuilder.create().build()` is slow.

Fixes gh-1764
10 years ago
Phillip Webb 830ce80824 Polish CLI init command
Rename a few classes and methods and extract some logic into helper
classes. Also change 2 char shortcuts to a single char.

Closes gh-1751
10 years ago
Phillip Webb b89e5e0ab7 Apply eclipse formatting rules
Apply eclipse formatting rules to b2fe2dd9.

See gh-1751
10 years ago
Stephane Nicoll b2fe2dd912 Add init command to the CLI
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
10 years ago
Phillip Webb cf24af0bfb Rework logging to prevent double initialization
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
10 years ago
Phillip Webb 2e7aa4685b Polish 10 years ago
Andy Wilkinson a2c5b6a7bb Preserve dependencies when uninstalling from the CLI
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
10 years ago
Andy Wilkinson f6bf32c3ee Add option help to the CLI's install and uninstall commands
Closes gh-1704
10 years ago
Dave Syer f9010c18cc Fix install command on Windows
Windows absolute paths cannot be processed by the CLI compiler, so the install
command wasn't working on Windows. This change converts ths path to a URI first
and then it works as a Spring Resource.
10 years ago
Spring Buildmaster 3e71a21b30 Next development version 10 years ago
Spring Buildmaster edb4b7ed7d Next development version 10 years ago
Stephane Nicoll 8ed461947f Improve RabbitMQ support in CLI
This commit deprecates the proprietary EnableRabbitMessaging annotation
in favour of the standard @EnableRabbit introduced as of Spring Rabbit
1.4.

Fixes gh-1494
10 years ago
Andy Wilkinson f5ab0cf2dc Update CLI install to prefer local snapshots to those in a remote repo
Previously, InstallCommand used a custom Grape root and then walked
the tree of files downloaded by Aether to determine which files it
should install or uninstall. In some scenarios two files for the
same module would be present: one named foo-1.0.0.BUILD-SNAPSHOT.jar
and one named foo-1.0.0.BUILD-20140905.091809-2.jar. The former is
from the local repository and the later is from a remote repository.
In this case, the visitor would do the wrong thing and the latter
would be installed into lib.

This commit updates InstallCommand to determine the jars that it
should process by consulting GroovyCompiler's classpath, rather than
by walking Aether's cache. This approach selects the correct jar as
Aether has already figured this out as part of resolving the
dependency. It also brings InstallCommand into line with JarCommand.

The previous implementation used Java 7-specific File APIs. As part
of the above-described change this usage has been removed. The
install command can now be used on Java 6.

Fixes gh-1515
10 years ago
Spring Buildmaster d63e4b4329 Next development version 10 years ago