Make sure that the title and description of each capability is
configurable and expose that information in the meta-data.
This typically allows to customize the header of each capability in the
UI and the description in help usage such as the optimized text output
for command line clients.
See gh-89
BOM id and version range can now be shared at the group level. If no
specific attribute is set, the defaults from the group are inherited.
Closes gh-105
Add explicit support for Bill Of Materials. When a dependency defines a
bom ID, the related bom is added to the project. The metadata are
validated on startup to make sure a dependency does not refer to an
unknown bom entry.
Closes gh-99
Add support for the dependency management plugin for Gradle so that BOMs
can be added to the project if needed.
Also, the Gradle plugin as from Spring Boot 1.3 has changed and this
commit brings a transparent support for it.
Closes gh-98
InitializrMetadataBuilder can now merge a number of resources into a
single meta-data instance. A new `/metadata/service` endpoint is now
available and exposes the service meta-data of the current instance.
Combining those two, it is now possible to bootstrap an instance without
a single line of configuration; instead, the meta-data are built from the
content of a json document describing the service meta-data. This
document can be fetched remotely (via the new endpoint) or loaded from
a local file.
Each capability, including the InitializrConfiguration has now a `merge`
method with a "last wins" strategy. For collections, only unknown
elements are added.
Closes gh-88
Provide a more flexible meta-data contract and clearly separate the
service configuration from the options used to generate a project.
The meta-data now defines a fixed set of core service capabilities. Each
capability has an id, a type, a description and a 'content'. The
following capability types are supported:
* text: single value
* single-select: a list of values, one value should be chosen
* hierarchical-multi-select: values of values, many values can be chosen
* action: a specific single-select that defines the action to invoke
An extension can now build its own meta-data instance more easily.
Closes gh-87
Add an extra group with the databases that Boot supports out-of-the-box.
This is a first step of a better user experience when someone selects
the `data-jpa` or `jdbc` starter as it requires a Database to operate and
none is provided by default.
Closes gh-84
Add an extra 'scope' attribute to any dependency (defaults to 'compile').
Update maven and gradle build templates to support compile, runtime,
provided and test dependencies. Also, dependencies are now sorted
according to their ids.
Closes gh-83
Previously, specifying a baseDir with a value holding a sub-directory
would fail as only the first directory got created. This commit allows
baseDir to hold a sub-directory as well (e.g. something like 'foo/bar').
Fixes gh-81
Previously, if a user choose 'SpringBoot' or 'Spring' as the name of the
project, the service will generate a `SpringBootApplication` or
`SpringApplication` respectively. Both of which leads to a compilation
failure since those names are already used in the current context.
The generation of the application name based on the project's name have
been moved to InitializrMetadata and two new properties have been
introduced:
* env.fallbackApplicationName defines the name of the application if the
one that was generated was invalid for some reasons
* env.invalidApplicationNames defines a list of application names that
should flagged as invalid. When the current candidate is equal to one of
them, the fallback should be used instead
These properties have default values that prevent such issue to happen
by default.
Fixes gh-79
Command line tools are invited to discover the HAL-compliant links
defined in the meta-data while Spring Boot CLI is a working client
application and requires a description of the capabilities in a more
high-level format.
Capabilities are now customized for those use cases.
Closes gh-77
Provide a polished version of the command-line service capabilities
with tables and support for the new version range.
Also support SpringBootCli explicitly so that the service capabilities
are rendered directly by the server instead of having the client parsing
the meta-data manually.
Closes gh-76
Previously, it was not possible to define the Spring Boot version that
a dependency requires. As a result, many new starters implemented as part
of Spring Boot 1.2 are not available.
Each dependency can now define a `versionRange` attribute that defines
the Spring Boot version range that it supports. The range is defined
either as a single version, in which case it defines that version and
any later versions or using brackets. A square bracket (`[` or `]`)
denotes an inclusive range while a round bracket (`(` or `)`) denotes an
exclusive range.
Bumped the current-metadata format to 2.1 to include this additional
`versionRange` attribute, that is
application/vnd.initializr.v2.1+json
Existing clients requesting v2 will not get any dependency that defines
a `versionRange` attribute.
Closes gh-62
Since Htmlunit does not provide a complete support for Javascript, smoke
tests are migrated to Gab (i.e. using Selenium and an actual browser).
This present a major challenge: it is not easy to assert the content of
a file that the browser downloads when it submits a form. First, the
browser should be configured to download the file directly instead of
opening a (native) pop-up asking the users where to download it. Then,
the tests should be aware of the location of the file in order to assert
it.
Hopefully, Firefox can be configured to achieve this goal.
Closes gh-75
A groovy-based project on Maven provides a better developer experience
if the sources are located in src/main/java and src/test/java.
This commit updates the generator to use this new location while keeping
the existing src/main/groovy project for Gradle builds.
Fixes gh-71
Remove `type` as a template variable since each action actually defines
the related type. This commit however does not address all the concerns
raised in gh-69; since the configuration is generic, there is no way to
know that a particular action handles one and only one type so removing
the type because it is redundant is not really possible.
Besides, the zip and tgz endpoints aren't exposed via configuration
either so offering such choice via the HAL-urls is not possible either.
Partially fixes gh-69
Add an explicit support for curl by returning a text description of the
service instead of the raw meta-data. curl users can still discover the
json metadata by setting the appropriate Accept header.
Also support for explicit "text/plain" if the user requires it. In this
case a generic text description is returned.
Closes gh-67
Previously the generated archive wasn't self contained and the user had
to create a dedicated directory before extracting it in case the archive
utility does not handle that use case (MacOS supports that by default).
A baseDir request attribute has been added and generate a base directory
in the archive when set. It is enabled by default in the web UI and takes
the same value as the artifactId. Other clients are unaffected by this
change (and shouldn't probably).
Note that the legacy HTML form isn't impacted by this change either as
older STS versions expect the archive to have a very specific format.
curl-based tools can use that new baseDir request parameter to specify
that a base directory is required, something like
curl https://start.spring.io/starter.tgz -d baseDir=my-project
Closes gh-65
If Spring Boot 1.2 or later is used, the generated project uses the new
SpringBootApplication annotation as a replacement for what used to be
configured by Configuration, ComponentScan and EnableAutoConfiguration.
Also add an infrastructure to parse and compare versions.
Closes gh-46
Previously, the Assert helpers were located in the support package that
is also used by some support classes in the production code. Having both
test helpers and tests in the same package is a bit confusing.
Those test helpers are now relocated to a dedicated test package.
The 'name' field can now be used to customize the name of the generated
application (and its test counterpart). A default application name is
used If no suitable identifier can be inferred from the specified name.
Concretely, this means that the default application name is no longer
`Application` but `DemoApplication` since the default name is `demo`.
Closes gh-60
Previously if a project was generated with no defined dependency; a
metric with id 'counter.initializr.dependency.' was published. We now
make sure to properly identify that default use case and no metrics gets
published in such a case.
Fixes gh-57
Instead of doing a strict equality between the expected media type
and the one received in the response, we use isCompatibleWith that
ensure that at least the expected capabilities are present.
Style is the only parameter that deviates from the default names in the
metadata. As 'dependencies' is the name used in the metadata, it can be
used as an alias of style. This simplifies the HAL-generated URLs
Fixes gh-50
Update the metadata format in a non backward compatible way to ease
the use of the service from 3rd party clients. The updated metadata
format is now more descriptive and HAL-compliant and can be used with
Spring HATEOAS to build a client.
Metadata v1 is still served to preserve backward compatibility with
Spring Boot 1.2.0.RC1.
Closes gh-49
This commit adds a 'tags' attribute to each type. Two tags are currently
available:
1. build defines the build system that should be included in the project
(maven and gradle)
2. format defines the format of the project (build for the build file and
project for a project archive)
When a type id is specified, the build tag is used to figure out which
build system should be used. If no type is specified we fallback to Maven
as we were already doing.
Fixes gh-43
This commit improves the structure of the type id as it may be used by
third party clients. The id now defines the build system and the nature
of the project.
Because STS hardcodes those IDs, a new (deprecated) property on type
has been introduced to keep track of them. When serving the legacy HTML
page that STS parses, those ids are used instead.
Fixes gh-39
This commit updates the configuration format and JSON metadata output
to support an additional description attribute.
The description attribute is meant to further describe the purpose of the
dependency. This is a minor update to the JSON format that is fully
backward compatible.
Fixes gh-40
Prior to this commit, the browser was "guessing" the file name to use for
Maven and Gradle build files. This commit harmonizes the endpoints so
that they provide a Content-Disposition header with a preferred file
name.
This commit improves the structure of the type id as it may be used by
third party clients. The id now defines the build system and the nature
of the project.
Fixes gh-39
This commit generates an archive name that is consistent with the
chosen artifactId for the project. This prevents all archives to be
named 'starter.zip'. If the custom artifact contains special
characters, these are encoded (spaces are replaced by _ which seems a
sensitive default)
Fixes gh-36
This commit fixes a regression introduced by the library refactoring.
Previously, if no dependency was selected, the default
'spring-boot-starter' was added to provide the necessary base
dependencies.
This commit adds a addDefaultDependency on ProjectRequest that
adds that dependency. It can be overridden if the default needs to be
different.
Fixes gh-34
This commit adds several project related metrics that are recorded
using the standard CounterService.
The following metrics are managed:
* `counter.initializr.requests` sums the total number of requests, be
it for a project or a simple build file
* `counter.initializr.dependency.xyz` represents the number of times
the xyz dependency was requested. If the dependency is requested
through an alias, it is consolidated using the standard id
* `counter.initializr.type.xyz` represents the statistics per project
type (i.e. starter.zip, pom.xml, etc)
* `counter.initializr.java_version.xyz` represents the statistics per
java version
* `counter.initializr.packaging.xyz` represents the statistics per
packaging (war, jar)
* `counter.initializr.language.xyz` represents the statistics per
language (java, groovy)
* `counter.initializr.boot_version.xyz` represents the statistics per
Spring Boot version
The statistics are recorded by default using a
ProjectGenerationListener implementation. This can be further
customized by overriding the default ProjectGenerator bean provided
through auto configuration.
Fixes gh-32
This commit updates all consumers of the InitializrMetadata to go
through an InitializrMetadataProvider instead of having a direct
handle to the metadata instance.
A default InitializrMetadataProvider implementation that looks up
for some metadata from projects.spring.io has also been added.
That method is actually cached with a TTL of 10 minutes. This
allows the service to update itself automatically when such
metadata are updated in Sagan.
Fixes gh-26
This commit restores the previous HTML page that is currently used by
the STS wizard at a different location. This allows a single instance
to serve both the new UI and the (now) STS-specific form.
The LegacyStsController can be used to serve that endpoint and is not
auto configured. app.groovy has been updated to explicitely import that
bean.
The tests infrastructure has been abstracted a bit so that both pages
are actually tested with a set of common tests.
Fixes gh-33
This commit adds the '/spring' endpoint that is used to download the
Spring CLI distribution bundle. Instead of relying on the presence of
a local 'spring.zip' file uploaded as part of the application, a
redirect to a configurable repository is used.
It is possible to download both the zip and the tar.gz distribution
by specifying the extension in the url (i.e. /spring.tar.gz provides
the tar.gz distribution.
Fixes gh-31
This commit adds JSON structure validation tests to ensure that the
output is backward compatible with older versions if we enhance it
in the future.
Partly fixes gh-21
This commit allows any dependency to be tagged with a facet. A facet
is a simple name that can be used to further tune the project request
if necessary.
Prior to this commit, the list of dependencies that were related to the
web was hardcoded. This was used for special handling such as adding
a dependency automatically if necessary of creating additional
resources in the project.
This logic was moved to a standard 'web' facet that any dependency
can declare through configuration.
Fixes gh-30
This commit allows to specify an arbitrary number of aliases for a
dependency. A project can be generated using that dependency either
referring to its main id or any of its registered aliases.
Fixes gh-29
Prior to this commit, only spring boot starters can be added as project
dependency using a simple String denoting the suffix of the artifactId.
The standard 'org.springframework.boot' and 'spring-boot-starter-'
artifactId prefix were assumed.
This commit allows to define arbitrary dependencies with arbitrary
identifiers; the groupId, artifactId and version of the dependency can
be specified. Internally, all dependencies are converted to that format
even the ones defined as standard spring boot starters.
To allow that, a ProjectRequest is now resolved against the initializr
metadata. If a request defines an unknown dependency, a simple String
will be still considered a spring-boot-starter but a more complex
unknown id will lead to an exception (e.g. 'org.foo:bar').
Fixes gh-17
Stephane Nicoll