Note that the custom `CommandLineContentNegotiationStrategy` has been
adapted to the changes in the `ContentNegotiationStrategy` contract done
in https://jira.spring.io/browse/SPR-16624.
Closes gh-648
This commit reverts to `@RequestMapping` as certain endpoints are
invoked with `GET` or `POST`.
This is a temporary measure as we need to figure out and properly
document allowed methods for all endpoints
Closes gh-615
This commit upgrades to Spring Boot 2.0.0.
Please note that this commit does not change metrics names to use new
features of Micrometer yet (see gh-526)
Closes gh-611
This commits upgrade to Kotlin 1.2.20 and uses the new stdlib artifact
names. As a result, 2.0 milestones prior to Spring Boot 2.0.0.RC1 are
no longer supported.
Closes gh-576
This commit replaces Google Analytics with Tag Manager in the official
start.spring.io service instance.
The code section has been moved from the end of the body to the end
of the head section.
Closes gh-525
This commit reuses the `RestTemplateBuilder` infrastructure wherever
a `RestTemplate` is required. This allows to customize the rest template
if necessary.
Closes gh-481
This commit derives the package name of the application from the
artifact's `groupId` and `artifactId`. Previously sources were put in a
package that mirrors the groupId value.
This goes against the "unique package per application" policy that we
try to enforce. Even if the package name value can be customized
manually, deriving it automatically from the values provided in those
fields will help structure codebases.
With this change, the package name is derived like this:
* groupId `com.example`, artifactId `bookmarks` -> package
`com.example.bookmarks`
* groupId `com.example`, artifactId `user-management` -> package
`com.example.usermanagement`
This commit fixes the package name generation on the server, but also
in the web interfaces when the user updates the form fields.
Fixes gh-421
Rather than creating a `CacheManager` ourselves, we now rely on JCache
to provide a `CacheManager` that we'll augment with the caches that
initializr needs.
If Initializr is embedded in another app and that app uses JCache, then
its cache manager will be transparently upgraded to define the caches
that initializr needs. If not, such caches will have to be created as
part of the custom config.
Also, caching only kicks in if required at the service level.
This commit also switches the cache implementation to EhCache 3.
See gh-389
The commons wrapper we were using didn't support executable files
so Ant seems like the best choice ultimately, even if it has a
lot of features we don't use or need.
This commit fixes several issues with the initial java migration.
On MacOS, the name of the temp directory can be `T` and the new tgz API
requires a parent folder whose name has at least 3 characters.
The Selenium tests require a more precise element to show the advanced
section.
The integration tests were generation the docs snippet on the wrong
accept header.
If we don't re-use an existing factory, the label doesn't change and
all the snippets get generated with the same identifier.
Remove explicit version from wiremock test
Add snippets attribute to build config
See gh-295
This commit commit adds restdocs and stub generators and initiate
a reference guide for Initializr.
Most of the controller tests now use MockMvc via a custom version
of the MockMvcClientHttpRequestFactory (from spring-test). The
snippet names are auto-generated in the form
<HttpMethod>/<path>[/queries(/<name-value)*][/headers](/name-value)*]
when there is a comma-separated value in a header it is
abbreviated as <first-value>.MORE.
Wiremock stubs are generated in the same form under
snippets/stubs (with ".json" as the
file extension).
The controller tests that stayed as full stack use a different
base class AbstractFullStackInitializrIntegrationTests.
A long JSON body can be broken out into separate snippets
for each field (or rather a list of fields supplied by the
user). This feature was already used with hard-coded snippets
in the wiki.
See gh-295
This commit makes sure that each dependency link is HAL compliant (like
the project types in the metadata). Links are grouped by relation with
well known relations to be defined (i.e. 'how-to', 'reference', 'home'
and so forth).
Each link can be "templated" (in the HAL sense) and only `{bootVersion}`
is supported at the moment. This is useful if a precise documentation
section should reference to the actual Stpring Boot version chosen by the
user.
Closes gh-279
