Table of Contents
The Build Init plugin is currently incubating. Please be aware that the DSL and other configuration may change in later Gradle versions.
The Gradle Build Init plugin can be used to bootstrap the process of creating a new Gradle build. It supports creating brand new projects of different types as well as converting existing builds (e.g. An Apache Maven build) to be Gradle builds.
Gradle plugins typically need to be applied to a project before they can be used (see Section 27.3, “Using plugins”). The Build Init plugin is an automatically applied plugin, which means you do not need to apply it explicitly. To use the plugin, simply execute the task named init where you would like to create the Gradle build. There is no need to create a “stub” build.gradle file in order to apply the plugin.
It also leverages the wrapper task from the Wrapper plugin (see Chapter 23, Wrapper Plugin), which means that the Gradle Wrapper will also be installed into the project.
The plugin adds the following tasks to the project:
The init supports different build setup types. The type is specified by supplying a --type argument value. For example, to create a Java library project simply execute: gradle init --type java-library.
If a --type parameter is not supplied, Gradle will attempt to infer the type from the environment. For example, it will infer a type value of “pom” if it finds a pom.xml to convert to a Gradle build.
If the type could not be inferred, the type “basic” will be used.
All build setup types include the setup of the Gradle Wrapper.
As this plugin is currently incubating, only a few build init types are currently supported. More types will be added in future Gradle releases.
The “pom” type can be used to convert an Apache Maven build to a Gradle build. This works by converting the POM to one or more Gradle files. It is only able to be used if there is a valid “pom.xml” file in the directory that the init task is invoked in or, if invoked via the “-p” commandline option, in the specified project directory. This “pom” type will be automatically inferred if such a file exists.
The Maven conversion implementation was inspired by the maven2gradle tool that was originally developed by Gradle community members.
The conversion process has the following features:
Uses effective POM and effective settings (support for POM inheritance, dependency management, properties)
Supports both single module and multimodule projects
Supports custom module names (that differ from directory names)
Generates general metadata - id, description and version
Applies maven, java and war plugins (as needed)
Supports packaging war projects as jars if needed
Generates dependencies (both external and inter-module)
Generates download repositories (inc. local Maven repository)
Adjusts Java compiler settings
Supports packaging of sources and tests
Supports TestNG runner
Generates global exclusions from Maven enforcer plugin settings
The “java-application” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “application” plugin to produce a command-line application implemented using Java
Uses the “jcenter” dependency repository
Uses JUnit for testing
Has directories in the conventional locations for source code
Contains a sample class and unit test, if there are no existing source or test files
Alternative test framework can be specified by supplying a --test-framework argument value. To use a different test framework, execute one of the following commands:
The “java-library” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “java” plugin to produce a library Jar
Uses the “jcenter” dependency repository
Uses JUnit for testing
Has directories in the conventional locations for source code
Contains a sample class and unit test, if there are no existing source or test files
Alternative test framework can be specified by supplying a --test-framework argument value. To use a different test framework, execute one of the following commands:
The “scala-library” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “scala” plugin to produce a library Jar
Uses the “jcenter” dependency repository
Uses Scala 2.10
Uses ScalaTest for testing
Has directories in the conventional locations for source code
Contains a sample scala class and an associated ScalaTest test suite, if there are no existing source or test files
Uses the Zinc Scala compiler by default
The “groovy-library” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “groovy” plugin to produce a library Jar
Uses the “jcenter” dependency repository
Uses Groovy 2.x
Uses Spock testing framework for testing
Has directories in the conventional locations for source code
Contains a sample Groovy class and an associated Spock specification, if there are no existing source or test files
The “groovy-application” build init type is not inferable. It must be explicitly specified.
It has the following features:
Uses the “groovy” plugin
Uses the “application” plugin to produce a command-line application implemented using Groovy
Uses the “jcenter” dependency repository
Uses Groovy 2.x
Uses Spock testing framework for testing
Has directories in the conventional locations for source code
Contains a sample Groovy class and an associated Spock specification, if there are no existing source or test files