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
This commit introduces a set of customizable defaults for the generated
project, that is: groupId, artifactId, version, name, description and
packageName.
This complement the existing configurable defaults that are already
provided for action type, build type, language, java version and spring
boot version.
Fixes gh-19
This commit splits the single file script in a library that can be
released and published to the central repository.
This allows anyone to start its own initializr instance with a
proper configuration file and the following simple script:
package app
@Grab('io.spring.initalizr:initializr:1.0.0.BUILD-SNAPSHOT')
class InitializerService { }
The integration tests have been migrated so that they run as
part of the build. Additional tests have been added to extract
the content of the generated archive and assert the directory
structure as well as the content of key files.
Fixes gh-20
This commit fully revisits the main UI of the service:
* upgrade to Twitter Bootstrap 3.2.x (CSS, theme, font, glyphs)
* add specific CSS
* add favicon
Besides, starters are now regrouped by themes and those themes
are nicely displayed in the UI
Fixes gh-23, gh-11
The instructions should be explicit and precise enough for
anyone to deploy to production now. There is a Bamboo job
that should be doing it, but we've had some issue with it and
it often fails, whereas manual pushes always work. You need
a Cloudfoundry account with access to the Sagan organization
to push to production (ask Trevor Marshall).
