MAVEN's Pom.xml file structure build configuration Build

In Maven's Pom.xml file, the build-related configuration contains two parts, one is <build>, and the other is <reporting> here we only introduce <build>.

1. In Maven's Pom.xml file, there are two types of <build>:

<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 https://maven.apache.org/xsd/maven-4.0.0.xsd" >
  ...
  <!--"Project Build" contains elements of the Basebuild set and the Build set-->
  <build>...</build>< c5/><profiles>
    <profile>
      <!--"Profile Build" contains elements of the Basebuild set only-->< c8/><build>...</build>
    </profile>
  </profiles>
</project>

Description

A <build> is called the project build, which is a direct child of <project>. Another <build> is called the profile build, which is the direct child element of <profile>.

The profile build contains the basic build elements, and the project build contains two special elements, the various < Directory> and <extensions>.

2. Basic build elements shared by the profile build and project build

1) Examples are as follows:

<build>
  <defaultGoal>install</defaultGoal>
  <directory>${basedir}/target</ Directory>
  <finalName>${artifactId}-${version}</finalName> ...
</build>

Description: Defaultgoal, the default goal or phase, such as Jar:jar or the package, to build the path of the result, the default is ${basedir}/target directory Finalname, The name of the final result of the build, which may be changed in other plugin

2) <resources>

Resources are often not code, not compiled, but some properties or XML configuration files, which tend to copy resource files from the source path to the specified destination path during the build process.

<resources> gives the specific path of each resource in the MAVEN project. Examples are as follows:

Description: The resource file involved in the Resources,build process TargetPath, the target path of the resource file filtering, whether the resource is filtered during the build process, the default is directory, the path of the resource file, the default is ${ Basedir}/src/main/resources/directory under includes, a set of file name matching pattern, the matching resource file will be built process excludes, a set of file name matching pattern, the matching resource file will be ignored by the build process. Resource files that are also matched by includes and excludes will be ignored. Filters, the path to the properties file that filters the resource file, is located in the ${basedir}/src/main/filters/directory by default. Several key-value pairs are defined in the properties file. During the build process, the variable (key) that appears in the resource file is replaced with the value corresponding to the key in the property file. The resource files involved in the testresources,test process are located by default in the ${basedir}/src/test/resources/directory. The resource files are not built into the target artifacts.

3) <plugins>

<plugins> gives the plug-ins used in the build process.

  <build> ...
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        < artifactid>maven-jar-plugin</artifactid>
        <version>2.6</version>
        <extensions >false</extensions>
        <inherited>true</inherited>
        <configuration>
          < classifier>test</classifier>
        </configuration>
        <dependencies>...</ dependencies>
        <executions>...</executions>
      </plugin>
    </plugins>
  </build>

Description

GroupId Artifactid version extensions, whether to load the extension of the plug-in, by default false inherited, the configuration of the plug-in can be inherited by (inheriting the other MAVEN project of the Pom), The default true configuration, the plug-in requires special configurations, between parent-child projects can be overwritten or merged dependencies, the plugin-specific dependency class library executions, A goal of the plug-in, which may contain multiple goal in a plug-in, is executed. A execution has the following settings: ID, uniquely identifies goals, goal to execute plug-ins (can have multiple), such as <goal>run</goal> phase, plug-in goal to embed in MAVEN phase to execute, such as verify inherited, whether the execution can inherit the configuration of a quilt item, the other configuration parameters of the execution

4) <pluginManagement>

The relationship between,<pluginmanagement> and <plugins> in <build> is similar to that of <dependencyManagement> and < The relationship between dependencies>. <plugin> is also configured in <pluginManagement>, and its configuration parameters are exactly the same as <plugin> in <plugins>. Just,<pluginmanagement> often appears in the parent project, where the <plugin> of the configuration is often common to the child project. In a subproject, as long as <plugin> declares the plug-in in <plugins>, the specific configuration parameters of the plug-in are inherited from the parent project <pluginManagement> the configuration of the plug-in, thus avoiding duplicate configuration in the subproject.

3. Project build-specific < Directory>

are often configured in the parent project for use by all parent-child projects. Examples are as follows:

  <build>
    <sourceDirectory>${basedir}/src/main/java</sourceDirectory>
    < Scriptsourcedirectory>${basedir}/src/main/scripts</scriptsourcedirectory>
    <testSourceDirectory >${basedir}/src/test/java</testSourceDirectory>
    <outputdirectory>${basedir}/target/classes </outputDirectory>
    <testoutputdirectory>${basedir}/target/test-classes</testoutputdirectory > ...
  </build>
</project>

The directory can use an absolute path, as shown in the example. If a relative path is used, all relative paths are under the ${basedir} directory.

4. Project Build-specific <extensions>

<extensions> is an additional tool that may be used in the execution of the build process and is added to classpath during the execution of the build.

You can also change the build process by building the plug-in <extensions> activation.

Typically, a specific implementation of the generic plug-in is given through <extensions> for the build process.

Examples of <extensions> use are as follows:

  <build> ...
    <extensions>
      <extension>
        <groupId>org.apache.maven.wagon</groupId>
        < artifactid>wagon-ftp</artifactid>
        <version>1.0-alpha-3</version>
      </extension >
    </extensions> ...
  </build>
</project>