If an elastic instance is available, publish a document to a
configurable index every time a `ProjectRequest` is handled by the
service.
In practice, this means that every attempt to generate a project leads to
a new document in the index. The document gathers the settings of the
required project, including invalid ones if any. If an exception is
thrown, the message of the cause is made available.
CloudFlare is explicitely supported and the IP and country of the request
is added to the document. If that information is not available and the
request contains a `X-Forwarded-For` header, the value is also associated
with the document. If an IPv4 is detected, it is set in a separate
`requestIpv4` property.
If for some reason the document could not be indexed, we attempt to retry
a configurable amount of times.
Closes gh-185
`1.3.2.RELEASE` is available now so there is no need to have a version
range on the snapshot. We don't need to copy/paste the version of the
bom in the actual dependency (that's the whole business of the bom
definition (including versions mapping according to the Spring Boot
version).
We want the `cloud-bom` to be automatically added when the data flow bom
is required so it is referenced as "additional BOM" as well.
Closes gh-189
Previously, Spring Initializr was refering to
`spring-cloud-starter-parent` as the BOM source for any cloud-related
dependencies.
This pom actually inherits from a specific version of Spring Boot and
brings all its dependency management. If the chosen boot version and the
one that the cloud bom brings do not match, inconsistent versions can
appear in the project.
The underlying issue was fixed by providing a new BOM that only provides
dependency management for the cloud-related bits.
Closes gh-116
As of Spring Boot 1.4, lombok is managed and we should no longer provide
a version for it. This commit makes sure to remove the version as of
Spring Boot 1.4
Closes gh-182
Spring Boot 1.4 has renamed the `spring-boot-starter-redis` to
`spring-boot-starter-redis`. This commit adds support for the former up
to 1.4 (exclusive) and the later as from 1.4
Closes gh-174
Spring Initializr does not support the provided scope properly with
Gradle as it relies on the `providedRuntime` configuration added by the
war plugin.
Lombok should be added with an optional flag anyway so until the
service properly supports it, lombok is defined again with the default
(compile) scope.
Closes gh-171
Update controllers to add an ETag information so that meta-data is cached
on the client.
Also enables the compression for json, css and html resources.
Closes gh-165
Remove the cloud dependency until Spring Boot itself provides a
dependency management for it. Also fix the scope so that lombok does
not leak in other projects.
Closes gh-154
Previously, all dependencies were considered equal and enough to compile
and start the simple auto-generated boot application. There are some
corner cases such as the JDBC drivers and the new Ratpack integration.
This commit adds an extra flag on a dependency that determines if it is
a starter or not (the default is true). When no starter dependency has
been selected for the project, the root starter (`spring-boot-starter`)
is automatically added.
Closes gh-159
This commit add two additional attributes to a dependency: weight
and keywords.
Weight is a numeric value (default to 0) that allows to order
dependencies search result in a sensible manner. This is a UI feature
only and is not exposed in the meta-data.
Keywords provides a list of words that are added to the source of terms
that the UI use to discover dependencies. It's not exposed either.
Both are exposed by the UI specific controller (`/ui/dependencies`).
See gh-145
* update keyboard shortcuts
* update dependencies descriptions
* add a second button down the page, after the dependencies
* when autocompleting a dependency that's already selected, unselect it
* synchronize packageName with groupId
* synchronize artifact name with artifactId
* fix tabindex order for form fields
See gh-145
There are various reports that things are broken with the first Spring
Boot 1.3 milestone and the currently released Spring Cloud version.
We're now hiding it until the underlying issue is fixed.
If a RedisConnectionFactory is detected the system will now export
metrics to redis every 5s (initializr.metrics.rateMillis). Metric
names are prefixed with <id>.<hex>. where <id> defaults to the
application name (initializr.metrics.id) and <hex> is unique. An
aggregator app can then pick up the values and (for instance)
continue counters across restarts.
The code is meant to be easier to upgrade Spring Boot 1.3
There are 2 beans that we can simply remove when we upgrade to 1.3.
Meanwhile, the app will run with 1.3 (or 1.2) for testing if you
uncomment the @ExportMetricWriter.
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
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
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
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
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 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 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 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
