Maven Parent-child relationship
The parent project must be packaged in a pom such as <packaging>pom</packaging>, and the parent project uses the <modules><module>msite-base</module ></modules> specifying sub-projects
Child project inherits most of the properties of the parent project using <parent> specified
Parent 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.hlzt.msite</groupId>
<artifactId>msite</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>msite</name>
<properties>
<msite.version>0.0.1-SNAPSHOT</msite.version>
</properties>
<modules>
<module>msite-base</module>
</modules>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.hlzt.msite</groupId>
<artifactId>msite-base</artifactId>
<version>${msite.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
Sub-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>
<parent>
<groupid>com.hlzt.msite</groupid >
<artifactId>msite</artifactId>
<version>0.0.1-SNAPSHOT</version>
< /parent>
<artifactId>msite-base</artifactId>
<name>msite-base</name>
<dependencies>
<dependency>
<groupId>org.apache.poi</groupId>
< artifactid>poi-ooxml</artifactid>
</dependency>
</dependencies>
<build >
<plugins>
</plugins>
</build>
</project>
maven Specifies the packing method type (Jar,war) and the package name,
Specify the name of the packaged file under some directories, exclude some directories, introduce some directories, filter the directory files
In general, I will specify the package in the parent project, and the packaging directory, so that the child project will be, the same rule to package.
Parent 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>maven_p</groupId> <artifactid>maven_p</ artifactid> <version>0.0.1-SNAPSHOT</version> <name>maven_p</name> <packaging> pom</packaging> <description/> <properties> <project.build.sourceencoding>utf-8</proje ct.build.sourceencoding> </properties> <dependencies> </dependencies> <modules> & lt;module>jetty_1</module> <module>jetty</module> </modules> <build> <plugins > <plugin> <!--the classifier element is used to help define some of the subordinate artifacts of the component output. The subordinate component corresponds to the main component, such as the main component is Kimi-app-2.0.0.jar the project may also be generated by using some plug-ins such as Kimi-app-2.0.0-javadoc.jar, Kimi-app-2.0.0-sourCes.jar such two sub-components. At this time, Javadoc,sources is the classifier of the two subordinate components, so that the subordinate members have their own unique coordinates.
-<!--the life cycle of MAVEN is abstract and actually requires plug-ins to complete tasks, which is done by binding the plug-in's target (goal) to the specific phase of the lifecycle (phase). For example: Bind the compile target of the Maven-compiler-plugin plug-in to the compile stage of the default life cycle to complete the project's source code compilation:--<artifactid>maven-jar-
Plugin</artifactid> <executions> <execution> <id>default-jar</id> <goals><goal>jar</goal></goals><!
--Packaged suffixes-<phase>prepare-package</phase><!--multiple stages of life, pre-packaged
<configuration> <includes><!--Introduction Path--
<include>**/model/**</include> </includes>
</configuration> </execution> <execution> <id>impl</id> <goals>
<goal>jar</goal></goals> <phase>prepare-package</phase> <configuration> <classifier>impl</classifier><!--***-impl . Jar--<excludes><!--exclusion-<exclude>**/model/**</exclude> </exc Ludes> <includes><!--Introduction-<include>**/i
Mpl/**</include> </includes> </configuration> </execution> <execution> <ID>WEB</ID&G
T <goals><goal>jar</goal></goals> <phase>prepare-package</phasE> <configuration> <classifier>web</classifier>
<includes> <include>**/web/**</include>
</includes> <excludes> <exclude>**/model/**</exclude>
</excludes> </configuration> </execution> </executions> </plugin> <plugin> <!--copy source files--<group Id>org.apache.maven.plugins</groupid> <artifactId>maven-dependency-plugin</artifactId> < Executions> <execution> <id>unpack-dependencies</id> <!--copy and unzip to the appropriate directory--&G
T <phase>package</phase> <goals> <goal>unpack-dependen Cies</goal> </goals> <configuration> <in cludetypes>war</includetypes><!--import File Type-<excludetransitive>true</excludetransitive
> <overWriteSnapshots>true</overWriteSnapshots> <type>war</type> <outputDirectory> <!--unzip-${project.build.directory}/${project.artifactid }.war </outputDirectory> </configuration> </ execution> </executions> </plugin> </plugins> </build> </project>
Maven's dependency
The dependency value introduces the dependency package dependency and dependent plug-in plugins, does not introduce other attributes, such as packaging can not be introduced through dependency, but through the introduction of parent-child relationship
<dependency>
<groupId>com.hlzt.platform</groupId>
<artifactid>platform-form </artifactId><!--introduction of dependent jars--
</dependency>
<dependency>
<groupId> Com.hlzt.platform</groupid>
<artifactId>platform-form</artifactId><!--Introducing war---
<type>war</type>
</dependency>
maven Lifecycle and plug-in bindings
A complete project build process typically includes steps such as cleanup, compilation, testing, packaging, integration testing, validation, deployment, and so on, and maven extracts a complete, easy-to-extend lifecycle. The life cycle of Maven is abstract, with specific tasks being done by plugins. Maven writes and binds the default plug-ins for most build tasks, such as plugins for compilation: Maven-compiler-plugin. Users can also configure or write plugins themselves.
1. Three sets of life cycles
MAVEN defines three sets of lifecycles: Clean, default, site, and each life cycle contains stages (phase). The three sets of lifecycles are independent of each other, but the phase in each life cycle are sequential, and the latter phase depend on the previous phase. When a phase is executed, the phase in front of it executes sequentially, but does not trigger any phase in the other two sets of life cycles.
1. 1 Clean Lifecycle Pre-clean: Perform pre-cleanup work; Clean: cleans up all the files that were built on the previous build; Post-clean: Perform cleanup work
1. 2 Default life cycle
The default life cycle is the core, and it contains all the steps that you really need to take when building a project. Validate Initialize generate-sources process-sources generate-resources process-resources: Copy and process resource files to target directory, ready to package; Compile: Compile the source code of the project; process-classes generate-test-sources process-test-sources generate-test-resources Process-test-resources test-compile: Compile the test source code; Process-test-classes Test: Run the test code; Prepare-package Package: Packaged as a jar or Pre-integration-test integration-test post-integration-test Verify install: Installs the well-made package to the local warehouse for use by other projects; Deploy: Install a well-made package to a remote repository for use by other projects;
1. 3 site Life cycle Pre-site site: Build the project's Web document; Post-site Site-deploy: Publish the generated site document
2. MAVEN's Plugin
MAVEN's core files are small, and the main tasks are done by plugins. Navigate to:% Local warehouse%\org\apache\maven\plugins, you can see some download good plugins:
A more detailed list of official plugins is available on the MAVEN website:
2. 1 plug-in target (Plugin goals)
A plug-in can usually accomplish multiple tasks, each of which is called a target of a plugin. When executing the MVN install command, the plug-in and execution plug-in targets are called as follows:
What are the targets for each plug-in, and the official documentation has a more detailed description: Maven Plugins
3. Binding a plug-in to the life cycle
The life cycle of MAVEN is abstract and actually requires a plug-in to complete the task, which is done by binding the plug-in's target (goal) to the specific phase of the lifecycle (phase). For example: Bind the compile target of the Maven-compiler-plugin plug-in to the compile stage of the default life cycle to complete the project's source code compilation:
3. 1 Built-in bindings
MAVEN binds plug-in targets by default for some lifecycle stages (phase) because different projects have different packaging methods for jars, wars, and Pom, so there are different binding relationships, where the binding relationships for the package of jar packages for the default life cycle are as follows:
In the second column, after the colon is the binding plug-in target, preceded by the prefix of the plugin (prefix), is a simplified way to configure and use the plug-in. Plugin Prefix
3. 2 Custom Bindings
The user can bind any plug-in target to the stage of any life cycle as needed, such as binding the jar-no-fork target of Maven-source-plugin to the package stage of the default life cycle, so that later execution mvn When the package command packages a project, the source code is packaged after the package phase, generating a source bundle such as the Ehcache-core-2.5.0-sources.jar form.
<build> <plugins> <plugin> <groupid>org.apach E.maven.plugins</groupid> <artifactId>maven-source-plugin</artifactId> <versi on>2.2.1</version> <executions> <execution> <id>
;attach-source</id> <phase>package</phase><!--The phase to bind to the life cycle--
<goals> <goal>jar-no-fork</goal><!--target of the plug-in to be bound-- </goals> </execution> </executions> </plugin> </plug Ins>. </build>