Spring Cloud supports Spring Boot 1.2 and 1.3 in two different release
lines so there is a need to change the Spring Cloud version according
to the chosen Spring Boot version.
Each bom can have arbitrary number of version mappings that permit
to customize the version and even the repositories used to build the
project
Closes gh-121
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 one rename the main application class everything works fine in the IDE
but fails on the command-line as the previous class name is hard-coded
in the POM. This is only strictly necessary when more than one main class
is present in the project.
Closes gh-120
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.
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
Spring Boot 1.3 snapshots had changed the id of the Gradle plugin from
spring-boot to org.springframework.boot.spring-boot. This change has
since been reverted.
This commit updates the Initializr to revert back to using the old id,
spring-boot. Some custom Spring Boot 1.3 logic remains: the dependency
management plugin is not applied to a Boot 1.3 project as Spring Boot
1.3 applies it automatically.
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
