DSL to customize project generation

Right now, the only sensible way to customize project generation is to fork the library and extend or modify ProjectGenerator. We intend to completely review that API so that these customizations can be applied without forking the library.

It is foreseen that we would need to provide a model for both the build and the source code so that these customisations can be applied without reinventing the wheel. There are some initiative out there but none that support Java, Groovy and Kotlin.

With that in place, we intend to provide a contribution model where one could drop a jar that would be automatically recognized and tune generated projects according to certain criteria.

This is work in progress and this issue will be updated once we get started on the implementation. Feedback more than welcome.

[snicoll]

A heads-up that we’ve made significant progress on this issue and we are about to merge a new API around project generation.

First of all, an abstraction model for the various assets of a project is provided:

• A build abstraction with a Maven and Gradle implementations that allows to tune the build. Each implementation has a BuildWriter to turn the model into an actual build
• A language abstraction with a Java, Groovy and Kotlin implementations, including a SourceCodeWriter for each
• A more high-level model for textual resources, .gitignore and basic configuration files

Several reusable utilities are also available:

• A TemplateRenderer abstraction (with a Mustache implementation) that allows to render (and cache) templates
• Writer abstraction with support of indentation
• Version model

The new API offers several hook points that one can use to contribute project assets:

• ProjectContributor, a high-level hook-point to add assets to a directory structure with convenient implementations to grab resources from the classpath or elsewhere
• Source file customizer to add annotations, methods or additional classes to a project
• Build customizer to add dependencies, plugins or other configuration items

Each project runs in its own dedicated context and the new API provides several conditions so that customizers are only applied when that makes sense. The following example illustrates how the Gradle build can be tuned to apply the war plugin when a war packaging is requested:

@Bean
@ConditionalOnPackaging(WarPackaging.ID)
public BuildCustomizer<GradleBuild> warPluginContributor() {
	return (build) -> build.addPlugin("war");
}

Contributions can be defined in external modules (a bit similar to auto-configurations in Spring Boot) with no change to the library necessary.

We are now in the process of reviewing the existing APIs to make sure all features are properly covered.

[snicoll]

@jjathman No, there’s no such initiative at the moment and that would not be in the scope of this issue anyway. We’re on Gitter if you want to chat.