to Maven 1. Maven uses pom as the project object model.
A simplest pom.xml
<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/maven-v4_0_0.xsd">
<!--
//The version number of maven used
-->
<modelVersion>4.0.0</modelVersion>
<!--
//Configuration of Maven private server, set warehouse, search according to the set order.
//Specify that this project is downloaded from those repositories, and writing in settings.xml is for all maven projects
-->
<repositories>
<!--
//This is generally the mirror image of the warehouse
-->
<repository>
<id>public</id>
<name>Team Nexus Repository</name>
<url>http://localhost:8081/nexus/content/groups/public</url>
<snapshots>
<!--
//snapshot version component download support
-->
<enabled>true</enabled>
<!--
//maven's update strategy, always means always, never means never. daily (default) means every day, interval:X means X minutes.
-->
<updatePolicy>always</updatePolicy>
</snapshots>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
</repository>
</repositories>
<pluginRepositories>
<!--
//This is generally the mirror image of the warehouse
-->
<pluginRepository>
<id>public</id>
<name>Team Nexus Repository</name>
<url>http://localhost:8081/nexus/content/groups/public</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</releases>
</pluginRepository>
</pluginRepositories>
<!-- //The project is published to the private server configuration, and the package is published in the project to the server configuration-->
<distributionManagement>
<repository>
<!--
//The ID here should be consistent with the ID in the server in settings.xml
-->
<id>nexus-releases</id>
<name>Team Nexus Release Repository</name>
<!--
//This URL is not the URL of the mirror, it is the URL of the warehouse
-->
<url>http://localhost:8081/nexus/content/repositories/releases</url>
</repository>
<snapshotRepository>
<id>nexus-snapshots</id>
<name>Team Nexus Snapshot Repository</name>
<url>http://localhost:8081/nexus/content/repositories/snapshots</url>
<!-- <uniqueVersion>false</uniqueVersion> -->
</snapshotRepository>
</distributionManagement>
<!-- //The configuration of Maven private server, set the warehouse, and search according to the set order. -->
<!--
//define variable
-->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!--
//Define spring.version variable, use "${spring.version}" below
-->
<spring.version>1.2.6</spring.version>
<developer.organization><![CDATA[xy公司]]></developer.organization>
</properties>
<!--
//maven coordinate definition of this project
//groupId, the organization ID, for example: org.codehaus.mojo, in the M2_REPO directory, it will be: org/codehaus/mojo directory. are the project coordinates
//artifactId, project name, for example: my-project, in the M2_REPO directory, it will be: org/codehaus/mojo/my-project directory. is the project module coordinates
//packaging, the packaging format can be: pom (that is, a copy of pom.xml (may be transcoded)), jar , maven-plugin , ejb , war , ear , rar , par
//version, version number, for example: 1.0, in the M2_REPO directory, it will be: org/codehaus/mojo/my-project/1.0 directory. The format is: major version. minor version. incremental version - limited version number.
//When SNAPSHOT is released, it will be placed in the SNAPSHOT version management office (there will be a timestamp after the version), and RELEASE or not will be added to the RELEASE version management office
//name, the name of this project, the name of the project, the document generated by Maven is used
//url, this project url, the URL of the project home page, the documentation generated by Maven is used
-->
<groupId>com.proserver</groupId>
<artifactId>CESmart</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>CESmart</name>
<url>http://www.midea.com.cn</url>
<!--
//The organization to which the project developer belongs
-->
<organization> demo </organization>
<!--
//URL of the organization to which the project developer belongs
-->
<organizationUrl> http://hi.baidu.com/banseon </organizationUrl>
<!--
//project description
-->
<description></description>
<!--
//Project developer description, see developers/developer element
-->
<developers></developers>
<!--
// Other contributor descriptions of the project, see developers/developer element
-->
<contributor></contributor>
<!--
//Project license description
-->
<licenses></licenses>
<!--
//This project depends on those maven projects (that is, the jar packages that others put in the warehouse (it is also a maven project, with their maven coordinates))
//To use other people's projects, refer to its maven coordinates
//maven will read the pom.xml files in them (jar packages), and load their projects depending on those maven projects, so you can reference other people's maven coordinates, regardless of their jar packages
//scope, compile(default), provided, runtime, test, system, import, that is, this jar can only be used there
//1.compile, the default value, applies to all stages and will be released with the project.
//2.provided, similar to compile, expects JDK, container or user to provide this dependency.
//3.runtime, only used at runtime, such as JDBC driver, suitable for running and testing phases.
//4.test, used only during testing, to compile and run the test code. Not released with the project.
//5.system, similar to provided, needs to explicitly provide the jar containing the dependencies, Maven will not look it up in the Repository.
//6.import, implement multiple inheritance (because each project can only declare a unique parent project), used to introduce multiple parent projects in <dependencyManagement>
//exclusions, is to exclude those packages, not included in this project, for multi-version management
//type, specifies the type of the dependency
//optional, whether the dependency is optional (default false), when true, the project (B) that introduces this project (A) will not import the package (C) introduced by this project (A), if B To introduce C, you need to import it yourself in the pom
//1. Assume that the above configuration is the configuration of project A, namely: Project-A --> Project-B. When compiling project A, it can pass normally.
//2. If there is a new project X that depends on A, namely: Project-X -> Project-A. At this point project X will not depend on project B. If project X uses functions involving project B, then the dependencies on project B need to be reconfigured in pom.xml.
//3. Reasons for configuring optional dependencies: 1. Save space such as disk and memory; 2. Avoid license permission problems; 3. Avoid classpath problems, etc.
//4. For example, a project similar to hibernate supports various databases such as mysql, oracle, etc., but when referencing this project, we may only use its support for mysql. Optional dependencies are configured in this project.
-->
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
<scope>test</scope>
<type></type> //What plugin is used for maven to handle dependencies
<optional></optional>
<exclusions>
<exclusion>
<groupId>groupC</groupId>
<artifactId>artifactC</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<!--
//Define the build behavior (that is, how to build the project (define how to generate what you want, such as jar packages, war packages))
-->
<build>
<!--
-->
<!--
//The file name of the generated file in the project directory when packaging is performed, and it will be changed to the file name when the project coordinates are defined during installation. They have the same content and different names.
-->
<finalName>redis</finalName>
</build>
</project>
Maven aggregation
1. Aggregate, aggregate multiple projects, each sub-project will become a module (each module is a Maven project), in the total project pom can use <modules> to aggregate together, the total project The output is pom. When packaging, it is not necessary to package one by one. In the total project packaging, it will be packaged for each module (of course, it can also be built one by one)
2. A Maven project contains multiple Maven sub-projects (embedded set), the following is the main pom.xml content:
<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.youzhibing.account</groupId>
<artifactId>account-aggregator</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging> //The output is set to POM
<name>Account Aggrregator</name>
<url>http://maven.apache.org</url>
<modules> //modules to aggregate
<!--
// Modules are written here
//The directory path where the project is located, such as: "../task-sla"
-->
<module>account-register</module>
<module>account-persist</module>
</modules>
</project>
Maven inheritance
1. Inheritance, the parent project puts the dependencies in <dependencyManagement>, so that the sub-project dependencies do not need to write the version number and scope (write groupId, artifactId), and use <parent> to introduce the parent project. , it will find the version number in the first <dependencyManagement> to ensure the same version number.
In parent project pom.xml <dependencyManagement> //Dependency management, which will not be introduced into the project, provides a way to manage dependency version numbers <dependencies> <dependency> </dependency> </dependencies> </dependencyManagement> subproject pom.xml <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.4.1.RELEASE</version> </parent>
Dependency transfer
1. A depends on B, B depends on C, then A depends on C (that is, the C package will be added)
2. A can use <exclusion> to exclude the dependency C (that is, not add the C package) when introducing B.
Dependency conflict
1 .It is the same package that introduces multiple versions at the same time. 2.
Short circuit priority is the version that can be added to the project
first . There is no such function, but there are package, compile, and install, but it can also be done with the specified version
<plugins> <plugin> <!-- // plugin coordinates --> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <version>2.2.1</version> <executions> <!-- // perform behavior control --> <execution> <!-- //Define the ID of a task --> <id>attach-sources</id> <!-- //Define the phase in which the work is performed --> <phase>package</phase> <goals> <!-- //Similar to executing mvn source:jar, it is the command to be executed --> <goal>jar-no-fork</goal> </goals> </execution> </executions> </plugin> </plugins>
Maven related commands (mvn is not used in Eclipse)
mvn -v View the maven version
mvn compile compile, compile the project. java text as
mvn test test, run test cases, generate test reports
mvn package package, generate jar, compiled .class, test Put the report in the target directory, generate the jar package of the project directory
mvn clean delete the target directory and the inside and file (.class)
mvn install install the jar package into the local warehouse, copy pom.xml, xxx.jar to the local maven warehouse, Change to the name xxx.pom, xxx.jar specified by the project, of course, there is
mvn deploy with the original pom.xml file in the jar. Upload and install the jar package into the server warehouse. The
maven life cycle (that is, each function (command) will go through those Phase work) The
maven phase describes cleaning , compiling ,
testing, packaging, integration testing, verification, deployment (install) .clean, clean up all the files generated by the last build 3.post-clean, execute the cleaned file default, build the project life cycle 1.compile, compile 2.test, test 3.package, package 4.install, deploy
site, generate project site life cycle
1. pre-site, work to be done before generating project site 2. site
, generate project site file
3. post-site, work to be done after generating project site
4. site- deploy, publish the generated site to the
maven plugin
on the server 1. The commands executed by maven are all done by executing the plugin. The plugin is also a maven project, which is also obtained by specifying coordinates.
2. Of course, most commands Maven already comes with, If you don't have it, you need to specify a plugin to complete it.
<build> <plugs> <plugin> <groupId>org.apache.maven.plugins</groupId>//A plugin for packaging the original code <artifactId>maven-source-plugin</artifactId> <version>2.4</version> <executions> //Execution parameter settings <execution> <id>add-resource</id> <phase>package</phase> //Execute when the package phase is executed <goals> //Generate goals <goal>jar-no-fork</goal> //Generate target command </goals> <configuration> //Configuration parameters <resources> //This element describes a list of all project-related resource paths, such as project-related property files, which are included in the final packaged file. <resource> //This element describes all project-related or test-related resource paths <directory>src/main/java</directory>//Describe the directory where resources are stored, the path is relative to the POM path <includes> //The list of included patterns, such as **/*.xml. (It is used to match those files to be typed into the package) <include>**/*.xml</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin> <plugs> </build>
Refer to the original text (detailed explanation of pom.xml configuration): http://blog.csdn.net/longeremmy/article/details/9670619
Reference to the original text (detailed explanation of pom.xml): http://blog.csdn.net/adeyi/article/ details/17259479
Reference text (maven optional dependencies): http://www.tuicool.com/articles/yaeIV3
Reference text (Dependency introduction): http://elim.iteye.com/blog/2057317
Reference text (pom. xml configuration details): http://www.cnblogs.com/skyme/archive/2011/08/19/2146145.html
Reference original text (source code packaging plug-in): http://www.tuicool.com/articles/NFvAbm
Reference Original text (source code packaging plug-in): https://my.oschina.net/xiaokaceng/blog/210498
Reference original text (source code packaging plug-in): http://blog.csdn.net/chs_jdmdr/article/details/42419191
Reference original text ( modules, parent, properties and import): http://www.cnblogs.com/youzhibing/p/5427130.html
Refer to the original text (detailed pom.xml configuration): http://www.cnblogs.com/yangxia-test/p/4409736.html
Refer to the original text (deploy error handling): http://www.javatang.com/archives/2010 /01/23/4518375.html
Reference text (Maven warehouse): http://juvenshun.iteye.com/blog/359256
Reference text (Maven module): http://www.cnblogs.com/xdp-gacl/p /4242221.html
Reference original text (Maven best practice: dividing modules): http://juvenshun.iteye.com/blog/305865