On start.spring.io, if you customize the artifactId it creates a zip file
with the same name. The `spring init` command did not have a similar
shortcut.
This commit updates the request to customize the artifactId if none is
set and a custom location was specified. Just as we check for the
presence of a dot to figure out if we have to extract the archive or not,
we check for it to generate an artifactId without an extension.
In practice, `spring init foo` creates a foo directory with a project
whose artifactId is `foo` and `spring init foo.zip` stores a foo.zip
file with the same project (i.e. the artifactId is `foo`).
Closes gh-3714
This commit enhances the CLI to use the repositories configured in the
profiles declared in a user's Maven settings.xml file during
dependency resolution. A profile must be active for its repositories
to be used.
Closes gh-2703
Closes gh-3483
Unfortunately, we have no other choice to flip the ignoreUnknownFields
attribute of `SecurityProperties` has many different target are now set
for that namespace outside the class. See gh-3445 for a potential way
to improve that.
Closes gh-3327
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
User can enable OAuth2 SSO by declaring the intent (@EnableOAuth2Sso)
and also configuring the client properties (spring.oauth2.client.*).
The spring.oauth2.sso.* are only needed to change the path for the
login (defaults to /login) - any other security configuration for the
protected resources can be added in a WebSecurityConfigurerAdapter
which carries the @EnableOAuth2Sso annotation.
* Automatically spin up Authorization Server and Resource Server
* Automatically configures method level security included OAuth2Expression handler
* Wrote extensive unit tests verifying default behavior as well as the auto-configuration backing off when custom Authorization/Resource servers are included
* Created org.springframework.boot.security.oauth2 subpackage to contain it
* Can also disable either resource of authorization server completely with a single property for each
* Print out the auto-generated secrets and other settings
* Added spring-boot-sample-secure-oauth2 to provide a sample that can be run and poked with curl as well as some automated tests.
* Make users ask for which servers to install by adding @Enable*
* User has to @EnableGlobalMethodSecurity instead of using properties files
Add Spring Security OAuth2 support to Spring Boot CLI
* Triggered from either @EnableAuthorizationServer or @EnableResourceServer
* Needs to have @EnableGlobalMethodSecurity to allow picking the annotation model.
* By default, comes with import support for @PreAuthorize, @PreFilter, @PostAuthorize, and @PostFilter via a single start import
* Also need import support for the enable annotations mentioned above.
* Added extra test case and sample (oauth2.groovy)
Rework 155c60b7 to structure the code consistently, in particular with a more
natural order of attributes. Update test to use non-default values to ensure
that the customization has been applied.
See gh-2793
Update the CLI init command to expose additional attributes supported
by Spring Initializr. These are: groupId, artifactId, version, name,
description and language.
Closes gh-2793 and gh-2907
Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
Spring Framework’s ParamterizedRowMapper has been deprecated since
3.1 and has been removed in 4.2. Spring Batch currently relies on
ParameterizedRowMapper, making it incompatible with 4.2. To allow us to
build successfully against 4.2, this commit ignores Spring Boot’s tests
that use Spring Batch’s JDBC support.
See gh-2575
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, 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
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
