Chapter 17. Build Init Plugin

Table of Contents

17.1. Tasks
17.2. What to set up
17.3. Build init types

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.

17.1. Tasks

The plugin adds the following tasks to the project:

Table 17.1. Build Init plugin - tasks

Task name Depends on Type Description
init wrapper InitBuild Generates a Gradle project.
wrapper - Wrapper Generates Gradle wrapper files.

17.2. What to set up

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.

17.3. Build init types

As this plugin is currently incubating, only a few build init types are currently supported. More types will be added in future Gradle releases.

17.3.1. “pom” (Maven conversion)

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

17.3.2. “java-application

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:

  • gradle init --type java-application --test-framework spock: Uses Spock for testing instead of JUnit
  • gradle init --type java-application --test-framework testng: Uses TestNG for testing instead of JUnit

17.3.3. “java-library

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:

  • gradle init --type java-library --test-framework spock: Uses Spock for testing instead of JUnit
  • gradle init --type java-library --test-framework testng: Uses TestNG for testing instead of JUnit

17.3.4. “scala-library

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

17.3.5. “groovy-library

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

17.3.6. “groovy-application

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

17.3.7. “basic”

The “basic” build init type is useful for creating a fresh new Gradle project. It creates a sample build.gradle file, with comments and links to help get started.

This type is used when no type was explicitly specified, and no type could be inferred.