How to install maven on windows

Known Issues

New attributes for URLs inheritance (see ) are not yet accepted during POM structure control on upload to the Central Repository: see MVNCENTRAL-4841 to track progress
If you are using Maven reporting, it might happen that you will get an exception which looks like this:

 Scanning for projects...
 Internal error: java.lang.NullPointerException -> 
org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
...
Caused by: java.lang.NullPointerException
    at org.apache.maven.model.plugin.DefaultReportingConverter.convert (DefaultReportingConverter.java:243)
...

This is caused by using a which does not contain a element.

Temporarily this issue can circumvented by adding an empty element inside the .

Step 7 — Verify Maven Installation

A beginner’s guide to install gcc and g++ compiler on windows 10

Now open console and execute the following mvn command.

OS	Task	Command
Windows	Open Command Console	c:\> mvn —version
Linux	Open Command Terminal	$ mvn —version
Mac	Open Terminal	machine:~ joseph$ mvn —version

Finally, verify the output of the above commands, which should be as follows −

OS	Output
Windows	Apache Maven 3.3.1 (r801777; 2009-08-07 00:46:01+0530) Java version: 1.7.0_60 Java home: C:\Program Files\Java\jdk1.7.0_60 \jre
Linux	Apache Maven 3.3.1 (r801777; 2009-08-07 00:46:01+0530) Java version: 1.7.0_60 Java home: C:\Program Files\Java\jdk1.7.0_60 \jre
Mac	Apache Maven 3.3.1 (r801777; 2009-08-07 00:46:01+0530) Java version: 1.7.0_60 Java home: C:\Program Files\Java\jdk1.7.0_60 \jre

Output

Windows

Apache Maven 3.3.1 (r801777; 2009-08-07 00:46:01+0530)

Java version: 1.7.0_60

Java home: C:\Program Files\Java\jdk1.7.0_60 \jre

Linux

Apache Maven 3.3.1 (r801777; 2009-08-07 00:46:01+0530)

Java version: 1.7.0_60

Java home: C:\Program Files\Java\jdk1.7.0_60 \jre

Mac

Apache Maven 3.3.1 (r801777; 2009-08-07 00:46:01+0530)

Java version: 1.7.0_60

Java home: C:\Program Files\Java\jdk1.7.0_60 \jre

Previous Page
Print Page

Reporters and Contributors of this release

Install jetbrains rider

We really value the contributions of these non committers, so this section is focused on those individuals. Descriptions of the issues fixed can be found at the .

Issue Reporters of this release: Benoit GUERIN, Christian Schulte, Elliotte Rusty Harold, Falko Modler, Francesco Chicchiriccò, Guillaume Nodet, guofei, Joseph Walton, Louis Mills, Mark Derricutt, Mark McKelvy, Mickael Istria, Nicolas Echegut, Nicolas Radde, Raphael Rösch, Ray Tsang, Robert Thornton, Rohan Padhye, Sergey Chernov, Stefan Oehme, Thibaud Lepretre, zhb.

Code Contributors of this release: Guillaume Nodet, Mickael Istria, Ray Tsang, Stefan Oehme, Joseph Walton, Bo Zhang, AElMehdi, Christian Schulte, Mao Shuai, MartinKanters, Sergey Chernov, Jesse Glick.

Many thanks to all reporters and contributors for their time and support.

Apache Maven Resources Plugin

Install visual studio

The Resources Plugin handles the copying of project resources to the output directory. There are two different kinds of resources: main resources and test resources. The difference is that the main resources are the resources associated to the main source code while the test resources are associated to the test source code.

Thus, this allows the separation of resources for the main source code and its unit tests.

Starting with version 2.3 this plugin uses the Maven Filtering shared component for filtering resources.

Goals Overview

The Resources Plugin copies files specified by Resource elements, to an output directory. The three variations below only differ in how the resource and output directory elements are specified or defaulted. The Resources Plugin has three goals:

resources:resources copies the resources for the main source code to the main output directory.

This goal usually executes automatically, because it is bound by default to the process-resources life-cycle phase. It always uses the project.build.resources element to specify the resources, and by default uses the project.build.outputDirectory to specify the copy destination.
resources:testResources copies the resources for the test source code to the test output directory.

This goal usually executes automatically, because it is bound by default to the process-test-resources life-cycle phase. It always uses the project.build.testResources element to specify the resources, and by default uses the project.build.testOutputDirectory to specify the copy destination.
resources:copy-resources copies resources to an output directory.

This goal requires that you configure the resources to be copied, and specify the outputDirectory.

Usage

General instructions on how to use the Resources Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our issue tracker. When creating a new issue, please provide a comprehensive description of your concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated. Of course, patches are welcome, too. Contributors can check out the project from our source repository and will find supplementary information in the guide to helping with Maven.

Examples

The following examples show how to use the Resources Plugin in more advanced use cases:

Specifying a character encoding scheme
Specifying resource directories
Filtering
Including and excluding files and directories
Escape filtering
Copy resources
Binaries filtering
Custom resources filters

Overview about the changes

There had been issues related to the project discoverytime which has been increased in previous version which influenced some of our users. This should have been fixed MNG-6311, MNG-6383 and MNG-6412.
The output in the reactor summary has been improved MNG-6391 cause it confused people. In Maven 3.6.0 the reactor summary now looks like the following:

 ------------------------------------------------------------------------
 Reactor Summary for parent 5.0.4-SNAPSHOT:

 parent ............................................. SUCCESS 
 domain ............................................. SUCCESS 
 service-client ..................................... SUCCESS 
 webgui ............................................. SUCCESS 
 service ............................................ SUCCESS 
 app ................................................ SUCCESS 
 appasm ............................................. SUCCESS 
 shade .............................................. SUCCESS 
 assembly ........................................... SUCCESS 
 ------------------------------------------------------------------------
 BUILD SUCCESS
 ------------------------------------------------------------------------
 Total time:  6.824 s
 Finished at: 2018-11-01T12:20:16+01:00
 ------------------------------------------------------------------------

The in the above output is the artifact name of the root module and the is the versions number for all modules in this reactor build.

If you have an aggregator pom which contains different modules with different versions each line will contain the appropriate versions which looks like this:

 ------------------------------------------------------------------------
 Reactor Summary:

 Apache Maven ACR Plugin 3.0.1-SNAPSHOT ............. SUCCESS 
 Apache Maven AntRun Plugin 3.0.0-SNAPSHOT .......... SUCCESS 
 Apache Maven Changelog Plugin 2.4-SNAPSHOT ......... SUCCESS 
 Apache Maven Changes Plugin 3.0.0-SNAPSHOT ......... SUCCESS 
 Apache Maven Clean Plugin 3.0.1-SNAPSHOT ........... SUCCESS 
 Apache Maven Compiler Plugin 3.7.1-SNAPSHOT ........ SUCCESS 
 Apache Maven Deploy Plugin 3.0.0-SNAPSHOT .......... SUCCESS 
 Apache Maven Documentation Checker Plugin 1.2-SNAPSHOT SUCCESS 
 Apache Maven EAR Plugin 3.0.0-SNAPSHOT ............. SUCCESS 
 Apache Maven EJB Plugin 3.0.1-SNAPSHOT ............. SUCCESS 
...

Step 5 — Set Maven Environment Variables

Add M2_HOME, M2, MAVEN_OPTS to environment variables.

OS	Output
Windows	Set the environment variables using system properties. M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.3.1 M2=%M2_HOME%\bin MAVEN_OPTS=-Xms256m -Xmx512m
Linux	Open command terminal and set environment variables. export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.1 export M2=$M2_HOME/bin export MAVEN_OPTS=-Xms256m -Xmx512m
Mac	Open command terminal and set environment variables. export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.1 export M2=$M2_HOME/bin export MAVEN_OPTS=-Xms256m -Xmx512m

Output

Windows

Set the environment variables using system properties.

M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.3.1 M2=%M2_HOME%\bin MAVEN_OPTS=-Xms256m -Xmx512m

Linux

Open command terminal and set environment variables.

export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.1 export M2=$M2_HOME/bin

export MAVEN_OPTS=-Xms256m -Xmx512m

Mac

Open command terminal and set environment variables.

export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.1

export M2=$M2_HOME/bin

export MAVEN_OPTS=-Xms256m -Xmx512m

Apache Maven PMD Plugin

The PMD Plugin allows you to automatically run the PMD code analysis tool on your project’s source code and generate a site report with its results. It also supports the separate Copy/Paste Detector tool (or CPD) distributed with PMD.

This version of Maven PMD Plugin uses PMD 6.29.0 and requires Java 7. See Upgrading PMD at Runtime for more information.

The plugin accepts configuration parameters that can be used to customize the execution of the PMD tool.

Goals Overview

This plugin has 4 goals:

pmd:pmd creates a PMD site report based on the rulesets and configuration set in the plugin. It can also generate a pmd output file aside from the site report in any of the following formats: xml, csv or txt.
pmd:cpd generates a report for PMD’s Copy/Paste Detector (CPD) tool. It can also generate a cpd results file in any of these formats: xml, csv or txt.
pmd:check verifies that the PMD report is empty and fails the build if it is not. This goal is executed by default when pmd:pmd is executed.
pmd:cpd-check verifies that the CPD report is empty and fails the build if it is not. This goal is executed by default when pmd:cpd is executed.

Usage

General instructions on how to use the PMD Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

Upgrading Notes

Note: Starting with PMD 6.0.0 and Maven PMD Plugin 3.9.0, the rules have been reorganized into categories, e.g. /category/java/bestpractices.xml. So when upgrading to Maven PMD Plugin 3.9.0 you should review your plugin configuration and/or custom ruleset. See Using Rule Sets for more information.

Examples

To provide you with better understanding of some usages of the Maven PMD Plugin, you can take a look into the following examples:

Upgrading PMD at Runtime
Multimodule Configuration
Remove Report
Target JDK and Toolchains
Using Rule Sets
Violation Checking
Analyzing JavaScript Code
Analyzing Java Server Pages Code
Finding duplicated code in C#

The detailed issue list

Sub-task

 - Convert Maven Settings Builder to JSR 330
 - Convert Maven Model Builder to JSR 330
 - Convert Maven Embedder to JSR 330

Bug

 - NullPointerException when pom.xml has incomplete XML tag
 - NullPointerException in DefaultExceptionHandler
 - DefaultModelValidator.validateId is inefficient
 - ComparableVersion.parseVersion is inefficient
 - DefaultArtifactVersion.parseVersion is inefficient
 - ArtifactHandlerManager.getArtifactHandler is inefficient
 - ExcludesArtifactFilter is a memory hog
 - NPE on reporting convertion (DefaultReportingConverter) when inheritance of with no reports
 - Child inherit.append.path attributes not defined in Maven POM XSD
 - Tycho-based modules do not build with 3.6.1 (works with 3.6.0)
 - Version comparison CLI does not work anymore
 - NPE in DefaultReportingConverter when reports has no InputLocation (using polyglot Maven)
 - NPE in DefaultReportingConverter (when reports injected by Repaint IO maven-tiles)
 - DefaultProjectBuildingRequest copy constructor does not copy all fields
 - Model location handling uses too much memory
 - Tycho cannot resolve project dependencies
 - Equal compile source roots are added multiple times
 - DefaultUrlNormalizer doesn't normalize all relative URIs
 - MavenRepositorySystemUtils.newSession() misses assignment
 - Maven XML parser does not accept '>' in XML processing instructions
 - Downgrade maven-resolver:1.4.0 to 1.3.3
 - Fix ExclusionArtifactFilter to respect wildcard
 - relative testSourceDirectory on macos throw duplicate class error
 - MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
 - MavenProject.getParentFile() not set when using ProjectBuilder.build(List<File>, ...)

Improvement

 - Migrate to non deprecated parts of Commons CLI
 - Prevent reparsing POMs in MavenMetadataSource
 - Add support for "release" qualifier
 - toolchain.xml file should support environment variables
 - Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion
 - Make Resolver debug log messages for projects and plugins consistent
 - Improve speed in collection merging
 - Speed improvements while parsing big reactor projects
 - Add a fast interpolator not using reflection
 - Lazily compute the ManagedVersionMap
 - Document maven.repo.local system property
 - Improve DefaultModelValidator performance
 - Speep up Artifact version check and Parent interpolation
 - Upgrade Plexus Utils to 3.2.1
 - StringSearchModelInterpolator introspects objects from Java API
 - Generalize 'resume from' message when build reactor fails

Test

 - Improve test coverage of org.apache.maven.model.path.DefaultUrlNormalizer

Task

 - improve documentation: dependency type = file classifier(optional)+extension + additional hints on dependency features

Dependency upgrade

 - Remove unused transitive dependencies of Guava
 - upgrade plexus-component-metadata to 2.0.0 to get reproducible META-INF/plexus/components.xml
 - Upgrade maven-assembly-plugin to 3.1.1
 - Upgrade Modello to 1.11
 - Upgrade Wagon to 3.3.3
 - Upgrade maven-resolver to 1.4.1

Apache Maven Install Plugin

The Install Plugin is used during the install phase to add artifact(s) to the local repository. The Install Plugin uses the information in the POM (groupId, artifactId, version) to determine the proper location for the artifact within the local repository.

The local repository is the local cache where all artifacts needed for the build are stored. By default, it is located within the user’s home directory (~/.m2/repository) but the location can be configured in ~/.m2/settings.xml using the <localRepository> element.

Goals Overview

The Install Plugin has 3 goals:

install:install is used to automatically install the project’s main artifact (the JAR, WAR or EAR), its POM and any attached artifacts (sources, javadoc, etc) produced by a particular project.
install:install-file is mostly used to install an externally created artifact into the local repository, along with its POM. In that case the project information can be taken from an optionally specified pomFile, but can also be given using command line parameters.
install:help displays help information on maven-install-plugin.

Important Note for Version 3.0.0+

The install:install goal does not support creating checksums anymore via -DcreateChecksum=true cause this option has been removed. Details can be found in MINSTALL-143.

Usage

General instructions on how to use the Install Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

Examples

To provide you with better understanding on some usages of the Maven Install Plugin, you can take a look into the following examples:

Installing a Custom POM
Generating a Generic POM
Creating Checksums
Updating Release Info
Installing an Artifact to a Specific Local Repository Path
Installing Secondary Artifacts

Install / Deploy

If you like to install or deploy artifacts by using the above setup you have to use the flatten-maven-plugin otherwise you will install/deploy artifacts in your repository which will not be consumable by Maven anymore. Such kind of setup will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>

 <build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>flatten-maven-plugin</artifactId>
      <version>1.1.0</version>
      <configuration>
        <updatePomFile>true</updatePomFile>
        <flattenMode>resolveCiFriendliesOnly</flattenMode>
      </configuration>
      <executions>
        <execution>
          <id>flatten</id>
          <phase>process-resources</phase>
          <goals>
            <goal>flatten</goal>
          </goals>
        </execution>
        <execution>
          <id>flatten.clean</id>
          <phase>clean</phase>
          <goals>
            <goal>clean</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
  </build>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

Apache Maven Assembly Plugin

Introduction

The Assembly Plugin for Maven enables developers to combine project output into a single distributable archive that also contains dependencies, modules, site documentation, and other files.

Your project can easily build distribution «assemblies» using one of the prefabricated assembly descriptors. These descriptors handle many common operations, such as packaging a project’s artifact along with generated documentation into a . Alternatively, your project can provide its own descriptor and assume a much higher level of control over how dependencies, modules, file-sets, and individual files are packaged in the assembly.

Currently it can create distributions in the following formats:

zip
tar
tar.gz (or tgz)
tar.bz2 (or tbz2)
tar.snappy
tar.xz (or txz)
jar
dir
war
and any other format that the ArchiveManager has been configured for

If your project wants to package your artifact in an uber-jar, the assembly plugin provides only basic support. For more control, use the Maven Shade Plugin.

To use the Assembly Plugin in Maven, you simply need to:

choose or write the assembly descriptor to use,
configure the Assembly Plugin in your project’s pom.xml, and
run «mvn assembly:single» on your project.

To write your own custom assembly, you will need to refer to the Assembly Descriptor Format reference.

What is an Assembly?

An «assembly» is a group of files, directories, and dependencies that are assembled into an archive format and distributed. For example, assume that a Maven project defines a single JAR artifact that contains both a console application and a Swing application. Such a project could define two «assemblies» that bundle the application with a different set of supporting scripts and dependency sets. One assembly would be the assembly for the console application, and the other assembly could be a Swing application bundled with a slightly different set of dependencies.

The Assembly Plugin provides a descriptor format which allows you to define an arbitrary assembly of files and directories from a project. For example, if your Maven project contains the directory «src/main/bin», you can instruct the Assembly Plugin to copy the contents of this directory to the «bin» directory of an assembly and to change the permissions of the files in the «bin» directory to UNIX mode 755. The parameters for configuring this behavior are supplied to the Assembly Plugin by way of the assembly descriptor.

Goals

The main goal in the assembly plugin is the single goal. It is used to create all assemblies.

For more information about the goals that are available in the Assembly Plugin, see the plugin documentation page.

Assembly and Component Descriptor Schemas (XSD)

http://maven.apache.org/xsd/assembly-2.0.0.xsd, http://maven.apache.org/xsd/assembly-component-2.0.0.xsd (for version 3.0 and higher)
http://maven.apache.org/xsd/assembly-1.1.3.xsd, http://maven.apache.org/xsd/component-1.1.3.xsd (for version 2.5.4 and higher)
http://maven.apache.org/xsd/assembly-1.1.2.xsd, http://maven.apache.org/xsd/component-1.1.2.xsd (for version 2.2 and higher)
http://maven.apache.org/xsd/assembly-1.1.1.xsd, http://maven.apache.org/xsd/component-1.1.1.xsd (for version 2.2-beta-4 — 2.2-beta-5)
http://maven.apache.org/xsd/assembly-1.1.0.xsd, http://maven.apache.org/xsd/component-1.1.0.xsd (for version 2.2-beta-1 — 2.2-beta-3)
http://maven.apache.org/xsd/assembly-1.0.0.xsd, http://maven.apache.org/xsd/component-1.0.0.xsd (for version 2.1 and lower)

Usage

General instructions on how to use the Assembly Plugin can be found on the usage page. Some more specific use cases are described in the examples given below.

Examples

To provide you with better understanding on some usages of the Assembly Plugin, you can take a look into the examples which can be found here.

Multi Module Setup

So now let us take a look into a situation where we have a multi module build. We have a parent pom and one or more children. The parent pom will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>18</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-parent</artifactId>
  <name>First CI Friendly</name>
  <version>${revision}</version>
  ...
  <properties>
    <revision>1.0.0-SNAPSHOT</revision>
  </properties>
  <modules>
    <module>child1</module>
    ..
  </modules>
</project>

The child will look like this:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.apache.maven.ci</groupId>
    <artifactId>ci-parent</artifactId>
    <version>${revision}</version>
  </parent>
  <groupId>org.apache.maven.ci</groupId>
  <artifactId>ci-child</artifactId>
   ...
</project>

Feature Summary

The following are the key features of Maven in a nutshell:

Simple project setup that follows best practices — get a new project or module started in seconds
Consistent usage across all projects — means no ramp up time for new developers coming onto a project
Superior dependency management including automatic updating, dependency closures (also known as transitive dependencies)
Able to easily work with multiple projects at the same time
A large and growing repository of libraries and metadata to use out of the box, and arrangements in place with the largest Open Source projects for real-time availability of their latest releases
Extensible, with the ability to easily write plugins in Java or scripting languages
Instant access to new features with little or no extra configuration
Ant tasks for dependency management and deployment outside of Maven
Model based builds: Maven is able to build any number of projects into predefined output types such as a JAR, WAR, or distribution based on metadata about the project, without the need to do any scripting in most cases.
Coherent site of project information: Using the same metadata as for the build process, Maven is able to generate a web site or PDF including any documentation you care to add, and adds to that standard reports about the state of development of the project. Examples of this information can be seen at the bottom of the left-hand navigation of this site under the «Project Information» and «Project Reports» submenus.
Release management and distribution publication: Without much additional configuration, Maven will integrate with your source control system (such as Subversion or Git) and manage the release of a project based on a certain tag. It can also publish this to a distribution location for use by other projects. Maven is able to publish individual outputs such as a JAR, an archive including other dependencies and documentation, or as a source distribution.
Dependency management: Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project’s clients can use to download any JARs required for building your project from a central JAR repository much like Perl’s CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with.

Usage

Prepare your project to use the maven-release-plugin

To be able to make a solid start with the maven-release-plugin, there are 2 things you should include in our pom:

the scm-section with a developerConnection
the maven-release-plugin with a locked version

The developerConnection contains the URL of the Source Control Management system pointing to the folder containing this pom.xml This URL is prefixed with scm: so the plugin can pick the right implementation for committing and tagging. The Maven SCM-page contains an overview all the supported SCMs, per SCM you can see how the URL should look like.

<project>
  ...
  <scm>
    <developerConnection>scm:svn:https://svn.mycompany.com/repos/myapplication/trunk/mycomponent/</developerConnection>
  </scm>
  
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>3.0.0-M4</version>
      </plugin>
    </plugins>
    ...
  </build>
  ...
</project>

The following are some common scenarios in preparing a release.

Use a different username in the SCM server than the one in the operating system

Most of the SCMs are simply executed as an external command as the current user on your system. If this username is not the same as the SCM username, you may need to set the following option:

mvn -Dusername=your_scm_username release:prepare

Set where to tag the files in Subversion

This example shows how to set the repository location for all tags to be created in Subversion. Note that this is not needed if you use the standard SVN layout, where the root project is in trunk, and there is a sibling tags directory.

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>3.0.0-M4</version>
        <configuration>
          <tagBase>https://svn.mycompany.com/repos/myapplication/releases</tagBase>
        </configuration>
      </plugin>
    </plugins>
    ...
  </build>
  ...
</project>

Do a Dry Run

Since the Release Plugin performs a number of operations that change the project, it may be wise to do a dry run before a big release or on a new project. To do this, commit all of your files as if you were about to run a full release and run:

mvn release:prepare -DdryRun=true

This will ask all the same questions, run the same tests, and output a copy of how the POMs will look after transformation. You can check the output and review the POMs, then run:

mvn release:clean

This will remove all of the files created above, and the project will be ready to execute the proper release.

Run in Batch Mode

Sometimes it is desirable to do the commit/tag process on a regular interval (e.g. to produce nightly or integration builds through a build server). To use the default inputs for the versions and tag information and not prompt for any values, use Maven’s --batch-mode setting:

mvn --batch-mode release:prepare

Use a staging repository

Sometimes it is desirable to deploy a pre-release to be approved before made publicly available. One option is to create release candidates versions using the release:perform goal, but the final deployed artifact will NOT be the exact one that has been approved as RCx.

A common solution is to use a staging repository, where a test-version is deployed with it’s documentation for review. If all is fine, it is then copied to the public repository. Using this strategy, the artifact that has been tested IS the one that is deployed.

The release:stage goal uses this strategy. It replaces the release:perform goal and does the same tasks, but requires a stagingRepository parameter. It will automatically re-configure the deploy and site-deploy goals to use the staging strategy.

After the release is complete, the release.properties and other release files will NOT be removed, so that you can still execute a release:rollback if some error has been detected and a new candidate must be created after some fixes. You just need to use a distinct tag in SCM, or rename the one that has been created if the SCM provider supports renaming tags.