1, Coordinate definition
<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.ioteye.maven</groupId> <artifactId>maven</artifactId> <version>1.0.0</version> <packaging>pom</packaging> <name>maven</name> <url>http://maven.apache.org</url> </project>
- packaging
Packaging method of maven project - classifier
Some ancillary artifacts, such as javadoc or sources, are used to help define the build output.
Note that you cannot directly define the classifier of the project, because the accessory components are not generated directly by default, but are generated with the help of additional plug-ins.
2, Dependency configuration
pom.xml contains one or more dependency elements under the dependencies tag to declare one or more project dependencies.
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> </dependencies>
- Type: the dependent type, corresponding to the packaging of the project coordinates
- scope: dependent range
- optional:
Application scenario: A depends on B, and B depends on C.
When B's option = true, if C is not explicitly introduced into A, A does not depend on C, that is, A can choose whether to rely on C.
The default is optional=false, and the subproject must depend on it. - exclusions: used to exclude transitive dependencies
3, Dependency range
compile: the default dependency range of scope is valid for compiling, testing and running three Classpaths, such as spring core
test: only valid for testing classpath, such as JUnit
Provided: valid for compiling and testing classpath, invalid at runtime. For example, servlet API, because the runtime container has been provided, maven does not need to be introduced repeatedly
Runtime: the test and runtime classpath is valid, such as the jdbc driver implementation. Only the JDBC interface provided by the JDK is required during compilation
System: consistent with the provided range, the dependencies in the system range are not resolved through the maven warehouse, but the specified dependency files are displayed through the systemPath element. Because it may cause the build to be non portable, it should be used with caution.
4, Dependency delivery
If the project's dependencies have their own dependencies, the project will also load the dependent dependencies. For example, spring core relies on Commons logging. If the project relies on spring core, it will also rely on Commons logging. When the declaration of a dependency is optional (true), the dependency is not passed.
5, Dependent mediation
Because of dependency passing, there will be different dependencies, including different versions of basic dependencies, such as a - > x (1.0), B - > C - > x (2.0). In this way, X has different versions. Which will be resolved by maven? Therefore, there are two principles of relying on Mediation:
The shortest path is preferred., As above, the path of X(1.0) is 1, and the path of X(2.0) is 2, so X(1.0) will be used
Under the same path, the first declaration takes precedence. When the path lengths are consistent, POM The top order in XML is used.
6, Dependency exclusion
It may exist in the project. For some reasons, if you do not want to introduce a transitive dependency of a dependency, you can use exclusions. For example, if you do not want to use commons logging when using spring, you can exclude it from spring core.
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>5.0.0.M5</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency>
7, Dependent version classification
For example, when using spring, you may use spring context, spring JDBC, spring TX, etc., but their versions are consistent. Considering the upgrade of later versions, you can define a spring Version properties to set the version uniformly.
<properties>
<spring.version>4.1.6.RELEASE</spring.version>
</properties>
In the dependent, use ${spring.version} instead
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>${spring.version}</version>
</dependency>
8, Dependency view and analysis
// View project dependency list mvn dependency:list // Displays the dependency list in a tree mvn dependency:tree // Dependency analysis mvn dependency:analyze
9, Life cycle
maven has three independent life cycles: clean, default and site.
- Clean: clean items
- default: build project
- Site: establish a project site
Each life cycle contains some phases, which are sequential, and the subsequent phases depend on the previous phases. default is the core part of the life cycle. It contains many stages. The following are common stages. The full number of stages can be seen http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference .
- validate: verify whether the project is correct
- Compile: compile the project source code
- Test: use a test suite to test the compiled code
- Package: package project code
- verify: check integration test results
- Install: install the packaged project code to the local warehouse
- deploy: copy the final packaging results to the remote warehouse
We can use the command line to execute the lifecycle phase
- mvn clean: call the clean phase of the clean life cycle, including pre clean and clean phases
- mvn test: call the test phase of the default life cycle, including all phases from validate to test
- mvn clean install: call the clean phase of the clean life cycle and the install phase of the default life cycle. The actual implementation is the pre clean of the clean life cycle. The clean phase and all phases of the default life cycle from validate to install
10, Multi environment configuration
If you need to configure environment variables for different environments, you can implement them through profiles.
<profiles>
<profile>
<id>test</id>
<!-- environment variable -->
<properties>
<env.name>test</env.name>
<env.version>snapshot</env.version>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>prd</id>
<properties>
<env.name>prd</env.name>
<env.version>bin</env.version>
</properties>
</profile>
</profiles>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>dev/*</exclude>
<exclude>prd/*</exclude>
</excludes>
</resource>
<resource>
<directory>${project.basedir}/src/main/resources/${env.name}</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
11, Plug in
11.1 plug in objectives
We know that the core of maven only defines the abstract life cycle, and the specific tasks are completed by the plug-in. The plug-in exists as an independent component, and maven will download and use the plug-in when necessary. For a plug-in, there may be multiple functions, and each function corresponds to a plug-in goal.
For example, Maven dependency plugin has multiple targets, such as dependency:list,dependency:tree,dependency:analyze, etc. before the colon is the plug-in prefix and after the colon is the plug-in target. Similarly, compiler: compile (the compile target of Maven compiler plugin) and surefire: Test (the test target of Maven surefire plugin).
When using, you need to bind the stages of the life cycle and the plug-in objectives to complete a specific construction task. For example, the compile target of Maven compiler plugin is bound to the compile phase of the default life cycle.
maven has built-in bindings between many life cycle stages and plug-in targets, such as the built-in plug-in binding relationship of default life cycle with package type of jar as follows:
| Life cycle phase | Plug in target | Perform tasks |
|---|---|---|
| process-resources | maven-resources-plugin:resources | Copy the main resource file to the main output directory |
| compile | maven-compiler-plugin:compile | Compile the main code to the main output directory |
| process-test-resources | maven-resources-plugin:testResources | Copy the test resource file to the test output directory |
| test-compile | maven-compiler-plugin:testCompile | Compile the test code to the test output directory |
| test | maven-surefire-plugin:test | Execute test cases |
| package | maven-jar-plugin:jar | Create project jar package |
| install | maven-install-plugin:install | Install the project output component to the local warehouse |
| deploy | maven-deploy-plugin:deploy | Deploy project output artifacts to a remote warehouse |
In addition to the built-in binding relationship, users can choose to bind a plug-in target to a stage of the life cycle. An example is to create the source code jar package of the project. You can use the jar no fork target of Maven source plugin to type the main code of the project into a jar file, which we bind to the verify phase.
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <version>3.0.1</version> <executions> <execution> <id>attach-sources</id> <phase>verify</phase> <goals> <goal>jar-no-fork</goal> </goals> </execution> </executions> </plugin>
The default binding phase has been defined for the target of many plug-ins at the time of writing, which can be viewed by using the command.
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:3.0.1 -Ddetail
You can see that there are in the output information.
source:jar-no-fork ... Bound to phase: package
That is, the life cycle phase of jar no for default binding is package.
11.2 plug in configuration
Users can configure plug-in parameters through command line and pom configuration
- For command line configuration, you can use the - D parameter in Maven command to specify a key value form to configure the parameters of the plug-in target. For example, Maven surefire plugin provides a maven test. Skip parameter. When it is true, the test execution will be skipped.
mvn install -Dmaven.test.skip=true
- The global configuration of the plug-in in pom is used for all tasks based on the target of the plug-in. The common Maven compiler plugin compiles the java version.
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.8</source> <target>1.8</target> <encoding>utf-8</encoding> </configuration> </plugin>
- Users can configure specific parameters for a plug-in task, bind maven antrun plugin: run to multiple life cycle stages and configure them differently.
<plugin> <artifactId>maven-antrun-plugin</artifactId> <version>1.8</version> <executions> <execution> <id>ant-validate</id> <phase>validate</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <echo>validate phase</echo> </tasks> </configuration> </execution> <execution> <id>ant-verify</id> <phase>verify</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <echo>verify phase</echo> </tasks> </configuration> </execution> </executions> </plugin>
11.3 plug in search
Can from http://maven.apache.org/plugins/index.html You can also use Maven help plugin to describe the plug-in.
// Query plug-in information mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:3.0.1 // Query plug-in target information mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:3.0.1 -Dgoal=jar-no-fork // Query details mvn help:describe -Dplugin=org.apache.maven.plugins:maven-source-plugin:3.0.1 -Ddetail
12, Maven built in variable
Maven has built-in directory variables, which are helpful for the configuration of file paths
${basedir} Project root directory
${project.build.directory} Build directory, default to target
${project.build.outputDirectory} Build process output directory. The default is target/classes
${project.build.finalName} Product name, default to ${project.artifactId}-${project.version}
${project.packaging} Packing type, default to jar
${project.xxx} current pom Contents of any node of the file