Configuration of dependent plug-ins in Maven POM file

POM (Project Object Model) is the working basis of Maven project XML exists in the project, where the details of the construction project are configured. It pre configures some default values for most projects, such as build directory, source directory src/main/java, test source directory src/test/java, and so on.

Here is a simple record of how to configure the most commonly used dependencies and plug-ins.

Super POM (top POM)

Super POM is Maven's default POM, and all POMS inherit this POM by default. In fact, this is a bit similar to the Object class in Java.
View detailed Super POM configuration

The POM of our project requires the following elements

project root
modelVersion - should be set to 4.0.0
groupId - project group id
artifactId - item id
Version - project version

An example

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1</version>
</project>

Project inheritance

Suppose you have a project. Com mycompany. App: my app: 1 the project structure is as follows

.
 |-- my-module
 |   `-- pom.xml
 `-- pom.xml

POM of my module The XML configuration is as follows

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-module</artifactId>
  <version>1</version>
</project>

If we want my module to inherit the pom configuration of the parent project, we can use pom The XML should read as follows

<project>
  <parent>
    <groupId>com.mycompany.app</groupId>
    <artifactId>my-app</artifactId>
    <version>1</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-module</artifactId>
  <version>1</version>
</project>

In addition, if we want the groupId and version of the project to be consistent with the parent project, we can remove the groupId and version

<project>
  <parent>
    <groupId>com.mycompany.app</groupId>
    <artifactId>my-app</artifactId>
    <version>1</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>my-module</artifactId>
</project>

If the project structure is as follows

.
 |-- my-module
 |   `-- pom.xml
 `-- parent
     `-- pom.xml

The pom configuration of my module project is as follows

<project>
  <parent>
    <groupId>com.mycompany.app</groupId>
    <artifactId>my-app</artifactId>
    <version>1</version>
    <relativePath>../parent/pom.xml</relativePath>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>my-module</artifactId>
</project>

Specify the path of the parent project pom file through the < relativepath > element

Dependency configuration

Simple configuration

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

A dependency includes at least three elements: groupId, artifactId and version. If the dependency is not of jar type, you need to specify the type, which is jar by default. If it is war, you need to specify < type > war < type >.

scope indicates when the dependency needs to be used and will affect the delivery of the dependency

The optional values of scope are:

compile
The default value when the scope is not specified is required during compilation, testing and running, and is available in all Classpaths.
provided
Similar to compile, it means that you want JDK or container to provide these dependencies at runtime. For example, when building a web project, we will set the dependent scope related to Servlet API to provided, because these classes should be provided by the container.
runtime
Indicates that dependencies need to be used when the project is running.
test
Indicates that dependencies need to be used when testing.
system
It is similar to provided, but local dependency. Sometimes when we use some dependencies that are not in the remote warehouse, we need to use this scope to indicate the use of local dependency.
import (available in Maven 2.0.9 or later)
This scope only supports the dependency whose type is configured as pom in the pom file, and can only be used in < dependencymanagement >. It is equivalent to introducing dependency management.

Due to the nature of dependency delivery, dependencies will automatically include related dependencies. Sometimes we want to use different versions of dependencies, we can exclude delivery dependencies, such as

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-a</artifactId>
      <version>1.0</version>
      <exclusions>
        <!-- exclude artifact-a Dependent on excluded-artifact -->
        <exclusion>
          <groupId>group-c</groupId>
          <artifactId>excluded-artifact</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-b</artifactId>
      <version>1.0</version>
      <!-- no jar Type, type needs to be specified -->
      <type>bar</type>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

Dependency Management

When several Maven projects have similar dependencies, we can create a parent project, configure these public dependencies, and then let these projects inherit the configuration of the parent project, which can save the amount of configuration code and facilitate unified version management.
For example, if we have three projects A, B and C, and all of them use JUnit, we can create A project parent and configure dependencies

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>parent</artifactId>
  <packaging>pom</packaging>
  <version>1.0</version>
    <dependencies>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
      </dependency>
    </dependencies>
</project>

Then, configure < parent > in A, B and C to inherit JUnit dependencies.
In one case, JUnit is required for A and B, but not for C, but we still need to conduct unified management in the parent project. Then we need to configure the < dependencymanagement > elements as follows

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>parent</artifactId>
  <packaging>pom</packaging>
  <version>1.0</version>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.test</groupId>
      <artifactId>project1</artifactId>
      <version>1</version>
    </dependency>
    <dependency>
      <groupId>com.test</groupId>
      <artifactId>project2</artifactId>
      <version>1</version>
    </dependency>
  </dependencies>
</project>

Dependencies in < dependencymanagement > are managed but not introduced. For example, our projects A and B need to use JUnit, so the configuration

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>A(or B)</artifactId>
  <packaging>jar</packaging>
  <version>1.0</version>
  <parent>
    <groupId>maven</groupId>
    <artifactId>parent</artifactId>
    <version>1</version>
  </parent>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
  </dependencies>
</project>

There is no need to specify a version number for the dependency because it has been specified in the parent project.
As long as the C project does not configure JUnit dependency, JUnit will not be introduced.

Plug in configuration

All the work of Maven is done by plug-ins, which are divided into two categories

Build plugins are executed when building a project and should be configured in the < build > element
Reporting plugins are executed when generating sites and should be configured in the < reporting > element

All plug-in configurations require three information: groupId, artifactId and version, which is similar to the dependent configuration. Similar to < dependencymanagement >, the plug-in configuration also has < pluginmanagement >, and the usage is the same. Refer to dependency management.

A common configuration looks like this:

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-myquery-plugin</artifactId>
        <version>1.0</version>
        <configuration>
          <url>http://www.foobar.com/query</url>
          <timeout>10</timeout>
          <options>
            <option>one</option>
            <option>two</option>
            <option>three</option>
          </options>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

The elements in < configuration > correspond to the parameters of the plug-in target. If you want to know the available parameters of a plug-in target, you can usually query through the following command

mvn <pluginName>:help -Ddetail -Dgoal=<goalName>

For example, if you want to know the parameters of the install target of the install plug-in, you can execute the command

mvn install:help -Ddetail -Dgoal=install

You will see the following output

Configuration of plug-in target

Usually, we need to configure the parameters when the plug-in target is executed. See the following example

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-myquery-plugin</artifactId>
        <version>1.0</version>
        <executions>
          <execution>
            <id>execution1</id>
            <phase>test</phase>
            <configuration>
              <url>http://www.foo.com/query</url>
              <timeout>10</timeout>
              <options>
                <option>one</option>
                <option>two</option>
                <option>three</option>
              </options>
            </configuration>
            <goals>
              <goal>query</goal>
            </goals>
          </execution>
          <execution>
            <id>execution2</id>
            <configuration>
              <url>http://www.bar.com/query</url>
              <timeout>15</timeout>
              <options>
                <option>four</option>
                <option>five</option>
                <option>six</option>
              </options>
            </configuration>
            <goals>
              <goal>query</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Put < configuration > in the < execution > tag. The < execution > tag specifies the stage and target of configuration application by configuring < phase >, < goal >, for example, the configuration with id of execution1 in the example will be applied to the query target in the test stage. We can see that there is no phase tag in < execution > with id of execution2, so when will it be applied?

If the target is bound to a phase by default, it is applied in this phase.
If the target does not have a default binding, it will not be applied.

What's the use of < ID > execution1 < / ID > here? In fact, when we execute an order, like

mvn maven-myquery-plugin:query

What configuration will it apply? If there is a configuration outside < executions >, it will be applied. If not, the < execution > configured above will not be applied. If we want to execute the target of the parameters configured above, we can add id to execute, such as

mvn maven-myquery-plugin:query@execution1

The configuration of execution1 will be applied during execution.

Ignore inheritance

By default, the child project will inherit the plug-in configuration of the parent project. If you do not want to inherit, you can configure the < inherited > tag

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.2</version>
        <inherited>false</inherited>
        ...
      </plugin>
    </plugins>
  </build>
  ...
</project>

Keywords: Java Maven eureka

Added by finalxerror on Wed, 02 Feb 2022 08:23:22 +0200

Programming VIP