Apache Maven is widely used in Java-based projects and known to the vast majority of enterprise developers. The wide-spread usage and the familiarity of this tool is certainly a benefit.

Maven is based on a convention over configuration approach which simplifies straightforward use cases. Maven's configuration, however, does not always provide flexibility. In fact, this inflexibility is sometimes a feature. Since it's cumbersome to change the default Maven project structure and build process, most of the Java enterprise projects come in a very similar and familiar way. New developers easily find their way through the project's build configuration.

The following snippet shows a typical example of a Maven project structure:

This will seem familiar to the majority of enterprise Java developers. This example web application is packaged as a WAR file.

One of the shortcomings of Apache Maven is its somewhat nontransparent way of defining used build plugins and dependencies thereof. Using the default build convention without explicitly specifying versions for plugins such as the Maven Compiler Plugin can result in unwanted changes of used versions. This violates the principle of repeatable builds.

Because of this, projects that require reproducibility often explicitly specify and override the plugin dependency versions in the POMs. By doing so, projects will be built using the same versions all the time, even if the default plugin versions change.

Super POM definitions are another common solution to specify exact plugin versions. Project POMs can inherit from parent projects and reduce boilerplate plugin definitions.

Developers can use the effective POM view that shows the resulting POM, after applying the default configuration and potential inheritance.

A typical issue with Maven POMs is that enterprise projects very often overuse the XML definitions. They prematurely introduce plugins or configuration that already would be covered by the build conventions. The following snippet shows the minimum POM requirements for a Java EE 8 project:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example.cars</groupId>
    <artifactId>car-manufacture</artifactId>
    <version>1.0.1</version>
    <packaging>war</packaging>

    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>8.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <finalName>car-manufacture</finalName>
    </build>

    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <failOnMissingWebXml>false</failOnMissingWebXml>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
</project>

The car manufacture application is built into a WAR artifact. The finalName overrides the implied name of the WAR file, here resulting in car-manufacture.war.

The specified Java EE 8 API is the only production dependency that a straightforward enterprise solution requires. Chapter 4, Lightweight Java EE will deeply cover the topic of project dependencies and their impact.

The provided properties tag removes the need to explicitly configure the build plugins. Maven plugins per convention uses properties for configuration. Specifying these will reconfigure the used plugin without needing to explicitly declare the full definitions.

The properties cause the project to be built using Java SE 8, with all source files considered to be encoded as UTF-8. The WAR file doesn't need to ship a web.xml deployment descriptor; this is why we instruct Maven not to fail the build on a missing descriptor. In the past, the Servlet API required deployment descriptors in order to configure and map the application's Servlets. Since the advent of Servlet API version 3, web.xml descriptors are not necessarily required anymore; Servlets are configurable using annotations.

Maven defines its build process in several phases, such as compile, test, or package. Depending on the chosen phase, multiple steps will be executed. For example, triggering the package phase will compile the main as well as test sources, run the test cases, and package all classes and resources into the artifact.

The Maven build commands are triggered in the IDE or the mvn command line, for example, as mvn package. This command triggers the package phase, resulting in a packaged artifact. More details on phases and functionality of Apache Maven can be found under its official documentation.