1. pom file
pom behalf of the project object model, which is the basic unit of work in Maven. It is an XML file, pom.xml files are always stored in the base directory of your project in. Pom contains objects that use Maven to build, pom.xml file contains configuration information for a variety of projects that require special attention, each project is only a pom.xml file.
There are some pom file used to describe the project node configuration information, such as:
1) project: Project root tag
2) modelVersion: pom model version, maven2 and only 3 to 4.0.0
3) groupId: This project is to identify the group. It is usually only in an organization or project. For example, a banking organization com.companyname.project-group has all of the banks and related items.
4) artifactId: This is the logo of the project. It is usually the name of the project. For example, consumer banking. groupId artifactId and together define the location of artifact in the warehouse
5) version: This is the version number of the project. In the artifact warehouse, which is used to distinguish between different versions
6) packaging: Packaging define Maven project, there are JAR, WAR and EAR three formats
The minimum pom file should have the following elements
<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.xdclass</groupId> <artifactId>demo</artifactId> <version>1.0-SNAPSHOT</version> </project>
Each file will inherit a parent pom pom, parent (Super) POM is the default Maven POM. All are inherited from a parent POM POM (whether explicitly define this parent POM). Parent POM contains some of the default settings can be inherited. Therefore, when you need to download Maven found in POM-dependent, it will default to the warehouse in the Super POM configuration.
You can use the following command to view the Super POM default configuration: mvn help: effective-pom
Here pom file used to configure the node dependent information
1) pom file dependencies for introducing dependent node, which a node may have multiple dependencies dependency
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> </dependencies>
2) file pom parent node for introducing the parent file pom
< Parent > < the groupId > xd.class < the groupId > group identifier Id parent project // < the artifactId > Demo-parent </ the artifactId > unique identifier of the parent project // < relativePath The > / </ relativePath The > // Maven first, find a parent pom projects in the current project, and then the location of the file system (relativePath), and then in the local repository, and then look in the remote repository. < Version > 1.0 </ Version > Version // parent project </ parent >
3) pom file module incorporated with node modules
Some multi-module Maven project will be made. This tag is used to specify all modules included in the current project. Maven after this project operations will make all the sub-module performs the same operation.
<modules> <module>com-a</module> <module>com-b</module> <module>com-c</module> </modules>
. 4) file properties pom pom node to define constants
<properties> <java.version>1.7</java.version> </properties>
The above constants may be referenced anywhere pom file by $ {java.version}.
5) pom file dependencyManagement node
Scenario: When a lot of time our project module, we rely on the package will be a lot of management problems, for proper operation of the project, must allow all use the same version of the sub-project dependencies and dependencies to ensure the application of the various projects and the same version, in order to ensure testing and release is the same result.
The benefits of using: After defining the parent module, sub-module does not directly correspond to rely on, but at the same time dependent can not add the version number, so that the benefits can be avoided are declared in each subproject use of when a version number, so would like to upgrade or switch to another version, only needs to be updated in the parent container, does not require any modification of a sub
Suppose you have a parent project, three sub-projects, the project's parent pom file as follows
<dependencyManagement> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.2.0</version> <scope>test</scope> </dependency> </dependencies> </dependencyManagement>
The three sub pom document are as follows: Note that three components corresponding to the three documents pom
子项目1： <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> </dependency> 子项目2： <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> </dependency> 子项目3： <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>5.0</version> </dependency>
And dependencies of the difference between dependencyManagement
1) dependencies not even write the dependency in the subproject, the subproject will still inherit the dependency from parent project (all inherited). In other words: do not use this sub-project dependencies will depend on the introduction of this
2) dependencyManagement in just declare dependencies, it does not implement the introduction, and the declaration of subprojects to be displayed dependent on the need. If you do not declare a dependency subproject, is not inherited from the parent project down; only write the dependencies in subprojects, and does not specify a specific version, will be inherited from the parent project, and version and scope They are read from a parent pom; Also, if the version number is specified in sub-project, it will use the specified jar in subprojects version.
2. Maven life cycle
Maven lifecycle of all of the build process is abstract and unified. The project includes the clean-up, initialization, compile, test, package, integration testing, validation, deployment and site generates almost all build steps.
The three maven build lifecycle:
1）clean
pre-clean before performing some cleanup work to be done
A build file generated on clean cleanup
post-clean after performing some cleanup work to be done
2）default
validate: validate the project is correct
compile: compile the project source code
test: using a suitable unit testing framework to test the compiled source code.
package: the compiled code is packaged into a format that can be released, such as jar or war
verify: run all checks, verify the package is valid
install: install maven local repository
deploy: deploy to a remote repository, so that other developers or projects can be shared
3）site
3. Maven commonly used basic commands
1) common commands
mvn package maven package
mvn generate-sources generate source code
mvn compile compile
mvn test-compile compiler test code
mvn test run test
mvn verify operation to check
mvn clean clean-up project
mvn install setup project to the local repository
mvn deploy publish the project to the remote repository
mvn dependency: tree display Maven dependency tree
mvn dependency: list display Maven dependency list
2) Common parameters
-D specify parameters, such as the skip unit testing -Dmaven.test.skip = true;
-P Profile specified configuration, can be used to distinguish the environment;
3) web-related commands
mvn tomcat: run start Tomcat
mvn Jetty: RUN start Jetty
mvn Tomcat: Deploy operational deployment package