maven.tar.gz

Maven is the de-facto build tool of choice for Java projects and has wide adoption at the enterprise level.

In this course, you will learn the fundamentals of Maven so that you can start to inject build automation into your own projects. You’ll start by exploring the basics such as plugins, goals, coordinates, and lifecycles.

In the latter half, you will dive into more advanced concepts such as dependencies, inheritance, aggregation, and build profiles. 

By the end of this course, you will have just the right amount of knowledge for you to quickly become productive when working with Maven.

Build Java Projects with Maven

We have already covered `<dependencyManagement>` and how it can be used to factor out common dependencies and their associated versions in one place. The `<pluginManagement>` tag offers similar functionality from the perspective of plugins. Consider the following setup that consists of a parent-POM project from which a child project inherits:

The parent POM file has the `exec-maven-plugin` configuration from the previous lesson, but it is wrapped inside the `<pluginManagement>` element. Note that adding the plugin details inside the `<pluginManagement>` element will not cause the plugin to execute for an inheriting child project. The child project must include the plugin coordinates in its `<build>` section for the plugin to execute with the configuration inherited from the parent POM. The parent POM looks as follows for this example:

```xml
<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <id>my-special-exec</id>
                        <phase>clean</phase>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                        <configuration>
                            <executable>${project.parent.basedir}/myScript.sh</executable>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </pluginManagement>
</build>
```

Note that we have specified the complete information required to run the plugin goal. Also, the path to the script is specified as `${project.parent.basedir}` because when we run the plugin goal from the child project, it'll have to refer to the parent's base directory. But we could also leave out details to be filled in by the inheriting child projects or have them override the existing details. Let's work with the exercise below to get more familiarity with `<pluginManagement>`.

The parent POM file has the `exec-maven-plugin` configuration from the previous lesson, but it is wrapped inside the `<pluginManagement>` element. Note that adding the plugin details inside the `<pluginManagement>` element will not cause the plugin to execute for an inheriting child project. The child project must include the plugin coordinates in its `<build>` section for the plugin to execute with the configuration inherited from the parent POM. The parent POM looks as follows for this example:

```xml
<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>3.0.0</version>
                <executions>
                    <execution>
                        <id>my-special-exec</id>
                        <phase>clean</phase>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                        <configuration>
                            <executable>${project.parent.basedir}/myScript.sh</executable>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </pluginManagement>
</build>
```

Note that we have specified the complete information required to run the plugin goal. Also, the path to the script is specified as `＄{project.parent.basedir}` because when we run the plugin goal from the child project, it'll have to refer to the parent's base directory. But we could also leave out details to be filled in by the inheriting child projects or have them override the existing details. Let's work with the exercise below to get more familiarity with `<pluginManagement>`.

This lesson talks about the pluginManagement element that can be used to consolidate plugin versions across child projects.

Theory

Plugin Management