To generate additional files, `doGenerateProjectStructure` should be
overridden but doing so doesn't work as `ProjectGeneratedEvent` is
publised as part as the base implementation.
See gh-552
Spring Boot 2.0.0.M6 offers a better integration with Kotlin. A
top-level `runApplication` function can be used to start the app and
additional dependency and plugin management are provided.
This commit simplifies the way a Kotlin-based project is generated when
running with a compatible version
Closes gh-534
This commit improves the cleanup algorithm to accept artifactId with
versions in them as it's used as part of the package name by
default. `foo-1.4.5` now generates `foo145`.
Closes gh-436
As of Spring Boot 2.0.0.M1, the SpringBootServletInitializer class has
been relocated to the support package. This commit fixes the generation
of war project as of that version.
Closes gh-502
This commit improves the `info` endpoint to contain a
`dependency-ranges` entry that is similar than the `bom-ranges` entry
for BOMs.
Each dependency that has a version mapping is listed with the range and
the related version. Some dependencies weren't managed and are now. For
those a `managed` version is used to indicate which Spring Boot versions
do not require to specify a version for the dependency.
Closes gh-453
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
This commit fixes the use of version token with Gradle. The standard
format with maven is "foo-bar.version" while Gradle uses
"fooBarVersion". The former format does not work with Gradle as it
attempts to interpret "-" as an operation.
A `VersionProperty` now defines a standard structure for the property
and allow to derive a camel cased version. That way, Maven still uses
the standard format while Gradle generates a consistent "fooBarVersion"
property.
Closes gh-396
Gradle 3.4 is known to be broken in IntelliJ IDEA and breaks the getting
started experience of generated projects. This commit uses Gradle 3.3
until a bug fix release of IJ is available.
Closes gh-380
This commit provides a complete entry for Spring Cloud task and clarify
that no more customization is required as of 1.4. Previously, the entry
did not have any groupId/artifactId pair, leading to a default (wrong)
groupId/artifactId to be generated.
Closes gh-341
This commit upgrades the wrapper version for Gradle 3 to the latest
version and enables it as of Spring Boot 1.5 (previously, Gradle 3 was
only applied as of Spring Boot 2).
Closes gh-380
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.
