The Build Init plugin can be used to create a new Gradle build. It supports creating brand new Gradle builds of various types as well as converting existing Apache Maven builds to Gradle.
The Build Init plugin supports generating various build types. These are listed below and more detail is available about each type in the following section.
Type | Description |
---|---|
pom |
Converts an existing Apache Maven build to Gradle |
basic |
A basic, empty, Gradle build |
java-application |
A command-line application implemented in Java |
java-gradle-plugin |
A Gradle plugin implemented in Java |
java-library |
A Java library |
kotlin-application |
A command-line application implemented in Kotlin/JVM |
kotlin-gradle-plugin |
A Gradle plugin implemented in Kotlin/JVM |
kotlin-library |
A Kotlin/JVM library |
groovy-application |
A command-line application implemented in Groovy |
groovy-gradle-plugin |
A Gradle plugin implemented in Groovy |
groovy-library |
A Groovy library |
scala-library |
A Scala library |
cpp-application |
A command-line application implemented in C++ |
cpp-library |
A C++ library |
The plugin adds the following tasks to the project:
Gradle plugins usually need to be applied to a project before they can be used (see Using plugins). However, the Build Init plugin is automatically applied to the root project of every build, which means you do not need to apply it explicitly in order to use it. You can simply execute the task named init
in the directory 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.
The Build Init plugin also uses the wrapper
task to generate the Gradle Wrapper files for the build.
The simplest, and recommended, way to use the init
task is to run gradle init
from an interactive console. Gradle will list the available build types and ask you to select one. It will then ask some additional questions to allow you to fine-tune the result.
There are several command-line options available for the init
task that control what it will generate. You can use these when Gradle is not running from an interactive console.
The build type can be specified by using the --type
command-line option. For example, to create a Java library project run: gradle init --type java-library
.
If a --type
option is not provided, Gradle will attempt to infer the type from the environment. For example, it will infer a type of “pom
” if it finds a pom.xml
file to convert to a Gradle build. If the type could not be inferred, the type “basic
” will be used.
The init
task also supports generating build scripts using either the Gradle Groovy DSL or the Gradle Kotlin DSL. The build script DSL defaults to the Groovy DSL for most build types and to the Kotlin DSL for Kotlin build types. The DSL can be selected by using the --dsl
command-line option. For example, to create a Java library project with Kotlin DSL build scripts run: gradle init --type java-library --dsl kotlin
.
You can change the name of the generated project using the --project-name
option. It defaults to the name of the directory where the init
task is run.
You can change the package used for generated source files using the --package
option. It defaults to the project name.
All build types also setup the Gradle wrapper.
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” command line 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.
Note that the migration from Maven builds currently only supports the Groovy DSL for generated build scripts.
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 Publish, 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, tests, and javadocs
-
Supports TestNG runner
-
Generates global exclusions from Maven enforcer plugin settings
The “java-application
” build 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 in Java -
Uses the “
jcenter
” dependency repository -
Uses JUnit 4 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:
-
gradle init --type java-application --test-framework junit-jupiter
: Uses JUnit Jupiter for testing instead of JUnit 4 -
gradle init --type java-application --test-framework spock
: Uses Spock for testing instead of JUnit 4 -
gradle init --type java-application --test-framework testng
: Uses TestNG for testing instead of JUnit 4
The “java-library
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
java
” plugin to produce a library implemented in Java -
Uses the “
jcenter
” dependency repository -
Uses JUnit 4 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:
-
gradle init --type java-library --test-framework junit-jupiter
: Uses JUnit Jupiter for testing instead of JUnit 4 -
gradle init --type java-library --test-framework spock
: Uses Spock for testing instead of JUnit 4 -
gradle init --type java-library --test-framework testng
: Uses TestNG for testing instead of JUnit 4
The “java-gradle-plugin
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
java-gradle-plugin
” plugin to produce a Gradle plugin implemented in Java -
Uses the “
jcenter
” dependency repository -
Uses JUnit 4 and TestKit 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
The “kotlin-application
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
org.jetbrains.kotlin.jvm
” and “application
“ plugins to produce a command-line application implemented in Kotlin -
Uses the “
jcenter
” dependency repository -
Uses Kotlin 1.x
-
Uses Kotlin test library for testing
-
Has directories in the conventional locations for source code
-
Contains a sample Kotlin class and an associated Kotlin test class, if there are no existing source or test files
The “kotlin-library
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
org.jetbrains.kotlin.jvm
” plugin to produce a library implemented in Kotlin -
Uses the “
jcenter
” dependency repository -
Uses Kotlin 1.x
-
Uses Kotlin test library for testing
-
Has directories in the conventional locations for source code
-
Contains a sample Kotlin class and an associated Kotlin test class, if there are no existing source or test files
The “kotlin-gradle-plugin
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
java-gradle-plugin
” and “org.jetbrains.kotlin.jvm
” plugins to produce a Gradle plugin implemented in Kotlin -
Uses the “
jcenter
” dependency repository -
Uses Kotlin 1.x
-
Uses Kotlin test library and TestKit 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
The “scala-library
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
scala
” plugin to produce a library implemented in Scala -
Uses the “
jcenter
” dependency repository -
Uses Scala 2.11
-
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 type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
groovy
” plugin to produce a library implemented in 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
The “groovy-application
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
application
” and “groovy
” plugins to produce a command-line application implemented in 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
The “groovy-gradle-plugin
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
java-gradle-plugin
” and “groovy
” plugins to produce a Gradle plugin implemented in Groovy -
Uses the “
jcenter
” dependency repository -
Uses Groovy 2.x
-
Uses Spock testing framework and TestKit 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
The “cpp-application
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
cpp-application
” plugin to produce a command-line application implemented in C++ -
Uses the “
cpp-unit-test
” plugin to build and run simple unit tests -
Has directories in the conventional locations for source code
-
Contains a sample C++ class, a private header file and an associated test class, if there are no existing source or test files
The “cpp-library
” build type is not inferable. It must be explicitly specified.
It has the following features:
-
Uses the “
cpp-library
” plugin to produce a C++ library -
Uses the “
cpp-unit-test
” plugin to build and run simple unit tests -
Has directories in the conventional locations for source code
-
Contains a sample C++ class, a public header file and an associated test class, if there are no existing source or test files