In particular, this commit replaces the GradleKts dedicated build system
in favor of a dedicated build system dialect.
Closes gh-851
Co-authored-by: Andy Wilkinson <awilkinson@pivotal.io>
This commit adds support for configuring several tasks at once using
a type. It also migrates the Kotlin support so that, instead of
configuring compileKotlin and compileTestKotlin, it configures all
tasks of type KotlinCompile at once.
See gh-890
This commit extends the build system and platform conditions to allow
for several values to be specified. Those conditions match if any of
the provided value matches.
Closes gh-888
This commit fixes the handling of configuration parameters so that
nested groups can be reused when requested with the same parameter
name. However, single parameters are additive.
Closes gh-867
This commit harmonizes assertions on text file content by sharing the
code that reads and validate candidates. Make sure that streams are
properly closed which may fix build failures on Windows.
See gh-862
While new scopes are available as of Gradle 3.4, the Spring Boot plugin
does not manage them in the `1.5.x` line. This commit introduces a
dedicated GradleBuildWriter for Gradle 3 that uses the previous scopes.
Closes gh-845
This commit adds support for an `HelpDocument` that can be generated
alongside the project. Such document can hold an arbitrary number of
sections with pre-defined sections such as "Getting Started" and "Next
Steps".
A default contributor retrieves the links for requested dependencies
and add them to the document.
Closes gh-353
Co-authored-by: Madhura Bhave <mbhave@pivotal.io>
This commit adds an optional module that gathers the opinions that are
used to generate a Spring Boot project.
Closes gh-340
Co-authored-by: Madhura Bhave <mbhave@pivotal.io>
Co-authored-by: Andy Wilkinson <awilkinson@pivotal.io>
This commit adds a project generation infrastructure based on the
abstraction defined thus far. Each project is described by a
`ProjectDescription` that provides the basic information about the
project such as language, build system, packaging, platform version
and more.
Each project runs in a dedicated `ProjectApplicationContext` where
contributors and customizers are elected to generate the project.
Customizers are meant to update the model based on the
`ProjectDescription` and other factors while contributors consume
models to generate project assets (build files, source files, etc).
Because project generation runs in a dedicated context, components can
be flagged with special conditions that enable them only when necessary.
Several conditions are provided in this commit to enable a component
based on the language, build system, packaging, platform version or
requested dependency.
See gh-340
Co-authored-by: Andy Wilkinson <awilkinson@pivotal.io>
Co-authored-by: Madhura Bhave <mbhave@pivotal.io>
This commit provides a Maven build system implementation with a writer
that can generate `pom.xml` files based on a configurable model.
Closes gh-814
Co-authored-by: Stephane Nicoll <snicoll@pivotal.io>
This commit provides a Gradle build system implementation with a writer
that can generate `build.gradle` and `settings.gradle` files based on a
configurable model.
See gh-814
This commit adds a build abstraction with a base model that concrete
build systems can reuse.
See gh-814
Co-authored-by: Stephane Nicoll <snicoll@pivotal.io>
This commit provides a Groovy language implementation with a writer that
can generate a `.groovy` source file based on a configurable model.
Closes gh-813
