# Chapter 15. Build Init Plugin

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 25.3, “Applying 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 21, Wrapper Plugin), which means that the Gradle Wrapper will also be installed into the project.

## 15.1. Tasks

The plugin adds the following tasks to the project:

Table 15.1. Build Init plugin - tasks

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

## 15.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.

## 15.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.

### 15.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

### 15.3.2. “`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
- 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

### 15.3.3. “`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
- 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

### 15.3.4. “`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
- 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

### 15.3.5. “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.