Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Maven 3.7 to Include Default Wrapper

Maven 3.7 to Include Default Wrapper

This item in japanese

Lire ce contenu en français

Maven 3.7.0 is slated to include a new wrapper designed to simplify portable builds between systems. This expands beyond Maven’s typical dependency resolution to include resolution of the correct version of Maven itself, removing the need to pre-configure most systems. As a result developers can more easily compile third party software projects and organizations can scale generic build nodes via continuous integration.

A large portion of the Java ecosystem uses Maven for two major parts: Maven is a build system for compiling software, and Maven central is a public repository of libraries so that the Maven build system can obtain needed files. Without the Maven build system, developers who want to work on a project must spend time learning a unique build system or setup for each project, thus taking time away from the work they set out to do. Instead, Maven sets out to share a common structure to all projects -- while some may complain about a lack of customization in Maven's pom.xml file, developers can learn one thing and then apply the same complaints and skillset to other projects without additional effort. Many Maven plugins are also available that can customize activities across the build phases. Inspiration for the wrapper came from Gradle, with the wrapper project emphasizing the inspiration.

Maven to date has been very stable for users, is available on most systems or is easy to procure: but with many of the recent changes in Maven it will be easier for users to have a fully encapsulated build setup provided by the project. With the Maven Wrapper this is very easy to do and it's a great idea borrowed from Gradle.


All Maven projects follow a similar folder structure and layout:

  • pom.xml indicates that a project is based on Maven and contains instructions on how to build it, the relationship between projects, and dependencies
  • src/main/java is the initial folder for custom code
  • src/main/resources is the location for code-like files, such as documents or configuration
  • src/main/java9 and similarly numbered folders indicate a multi-release JAR file, such as a library working on forwards-compatibility. These folders are less common, used mostly for libraries rather than applications that can specify their JRE version.
  • src/test/java is the location of unit tests, code that will validate much of the project's correctness
  • target is the destination of compiled class files and other artifacts

Ultimately Maven works by breaking software compilation into several needed phases, with key elements as follows:

  1. Someone configures a build system to have both a JDK and Maven.
  2. The build system launches a single job to compile the software in a lifecycle, some of which are:
    1. Clean: cleans up all older artifacts, ensuring no side-effects from previous builds.
    2. Compile: builds the software project
    3. Package: converts the compiled project to a deployable artifact
    4. A deploy or custom runner phase
  3. The compiled code or application is then sent to the appropriate area for distribution.

The Maven build wrapper makes an important improvement in step 1, removing the need to have Maven already present and configured on a system. While some development systems may benefit, the wrapper is not necessary for major Integrated Development Environments such as Apache NetBeans that already ship with an embedded Maven and full native support for Maven projects.

Rate this Article