According to POM 4.0.0 XSD, the build element is conceptually divided into two parts: BaseBuild (including the common parts of poject build and profile build, see below) and some advanced features included in poject 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 http://maven.apache.org/xsd/maven-4.0.0.xsd"> ... <!-- "Project Build" contains more elements than just the BaseBuild set --> <build>...</build> <profiles> <profile> <!-- "Profile Build" contains a subset of "Project Build"s elements --> <build>...</build> </profile> </profiles> </project>
BaseBuild element set
basic elements
<build> <defaultGoal>install</defaultGoal> <directory>${basedir}/target</directory> <finalName>${artifactId}-${version}</finalName> <filters> <filter>filters/filter1.properties</filter> </filters> ... </build>
1. defaultGoal: If no target is specified, the default value will be used. For example, executing mvn on the command line is equivalent to executing mvn install.
2. directory: build the storage directory of the target file, default in the ${basedir}/target directory;
3. FinlName: The file name of the build target file, by default, ${artifactId}-${version};
4. Filter: Define the *. properties file, which contains a list of properties that will be applied in the resources that support filters. That is, the "name=value" value pair defined in the filter file is applied to resources instead of the ${name} value at build time. Maven's default filter folder is ${basedir}/src/main/filters/.
resources
Another feature of build is to specify the location of resources in your project. Resources (usually) are not code, they are not compiled, but are bound to your project or used for other reasons, such as code generation.
<build> ... <resources> <resource> <targetPath>META-INF/plexus</targetPath> <filtering>false</filtering> <directory>${basedir}/src/main/plexus</directory> <includes> <include>configuration.xml</include> </includes> <excludes> <exclude>**/*.properties</exclude> </excludes> </resource> </resources> <testResources> ... </testResources> ... </build>
1. resources: A list of resource elements, each describing what and where files are associated with the project;
2. targetPath: Specify the folder where the build resource is stored. The default path is basedir. The target path of resources packaged in JAR is META-INF.
3. Filter: true/false, denoted as this resource, whether the filter is activated.
4. directory: Define the folder where resource is located, default is ${basedir}/src/main/resources;
5. includes: Specify the matching mode of the file as resource, and use * as wildcard character;
6. excludes: Specify which files are ignored. If a file conforms to both includes and excludes, excludes will take effect.
7. TesResources: Definition is similar to resource, but only used when testing. The default test resource folder path is ${basedir}/src/test/resources, and test resource is not deployed.
Plugins
<build> ... <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.0</version> <extensions>false</extensions> <inherited>true</inherited> <configuration> <classifier>test</classifier> </configuration> <dependencies>...</dependencies> <executions>...</executions> </plugin> </plugins> </build>
In addition to the standard coordinates of groupId:artifactId:version, plugin requires the following attributes:
1. Extensions: true/false, whether to load extensions of plugin, default to false;
2. inherited: true/false. Whether this plugin is applied to the child POM of the POM, the default is true;
3. configuration: configure the expected properties of the plugin. For example, we set the classifier attribute for maven-jar-plugin's Mojo.
If your POM has a parent, it can integrate plugin configuration from parent's build/plugins or plugin management.
To illustrate the relationship after inheritance, consider the following plugin s in parent POM:
<plugin> <groupId>my.group</groupId> <artifactId>my-plugin</artifactId> <configuration> <items> <item>parent-1</item> <item>parent-2</item> </items> <properties> <parentKey>parent</parentKey> </properties> </configuration> </plugin>
Then configure the following configuration in the inherited child POM:
<pre name="code" class="html"><plugin> <groupId>my.group</groupId> <artifactId>my-plugin</artifactId> <configuration> <items> <item>child-1</item> </items> <properties> <childKey>child</childKey> </properties> </configuration> </plugin></pre>
In this way, both child POM and parent POM have plugins whose groupId is my.group. Maven's default behavior is to merge the configuration s of the two plugins according to the attribute name. If there is an attribute in the child POM, the attribute is valid. If there is no attribute in the child POM, but there is one in the parent POM, the attribute in the parent POM is valid.
According to these rules, the above example will be obtained in Maven:
<pre name="code" class="html"><plugin> <groupId>my.group</groupId> <artifactId>my-plugin</artifactId> <configuration> <items> <item>child-1</item> </items> <properties> <childKey>child</childKey> <parentKey>parent</parentKey> </properties> </configuration> </plugin></pre>
By adding the combine.children and combine.self attributes to the configuration element, the child POM can control how Maven merges the configuration of the plugin.
Suppose this is the configuration of the child POM:
<pre name="code" class="html"><configuration> <items combine.children="append"> <!-- combine.children="merge" is the default --> <item>child-1</item> </items> <properties combine.self="override"> <!-- combine.self="merge" is the default --> <childKey>child</childKey> </properties> </configuration></pre>
Then, the effect of the merger is as follows:
Comb. children= "append" means that the attributes of the parent POM and the child POM are combined.
Comb. self= "override" means that the attributes of the child POM completely override the parent POM.
4. Dependencies: Dependencies have the same structure and functions as dependencies in base build s, but this is a plugin dependency, not a project dependency.
5. executions: A plugin can have multiple goals, each of which can be configured separately, and can even bind a plugin's goal to a different stage. executions configure the execution of the target of a plugin.
Assuming a binding antrun:run target to verify, we want the task to respond to the build folder while avoiding passing the configuration to his child POM. You will get an execution:
<pre name="code" class="html"><build> <plugins> <plugin> <artifactId>maven-antrun-plugin</artifactId> <version>1.1</version> <executions> <execution> <id>echodir</id> <goals> <goal>run</goal> </goals> <phase>verify</phase> <inherited>false</inherited> <configuration> <tasks> <echo>Build Dir: ${project.build.directory}</echo> </tasks> </configuration> </execution> </executions> </plugin> </plugins> </build></pre>
Id: Identification, used to distinguish from other executions. When this stage is executed, it will be shown in this form: [plugin:goal execution: id]. Here is: [antrun:run execution: echodir];
Goals: a list of goals for execution of a plugin;
phase: The stage of execution of the target. The specific value is shown in Maven's life cycle list.
Inherited: inherited or not;
configuration: configuration under specified goals.
Plugin Management
The configuration of plugin Management elements is the same as that of plugins, except that the configuration here is only for integration and is specified for use in the child POM. For example, in the parent POM, do the following configuration:
<build> ... <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.2</version> <executions> <execution> <id>pre-process-classes</id> <phase>compile</phase> <goals> <goal>jar</goal> </goals> <configuration> <classifier>pre-process</classifier> </configuration> </execution> </executions> </plugin> </plugins> </pluginManagement> ... </build>
In child POM, we only need to configure:
<build> ... <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> </plugin> </plugins> ... </build>
This can greatly simplify the configuration of children's POM.
Reporting
Reporting contains attributes that correspond to the site phase (see Maven Life Cycle). Specific Maven plug-ins can generate reports defined and configured under reporting elements, such as Javadoc reports.
<reporting> <outputDirectory>${basedir}/target/site</outputDirectory> <plugins> <plugin> <artifactId>maven-project-info-reports-plugin</artifactId> <version>2.0.1</version> <reportSets> <reportSet></reportSet> </reportSets> </plugin> </plugins> </reporting>
For reportSets:
<reportSets> <reportSet> <id>sunlink</id> <reports> <report>javadoc</report> </reports> <inherited>true</inherited> <configuration> <links> <link>http://java.sun.com/j2se/1.5.0/docs/api/</link> </links> </configuration> </reportSet> </reportSets>