1. Life cycle
Clean: delete the old file class bytecode file obtained from previous compilation
Compile compile: compile java source program into class bytecode file
Test test: automatic test, automatically call the junit program
Report report:
package the package of the result of the test program execution : War package for dynamic web projects and jar package for java projects.
Installation: package and publish the project to a local warehouse for use by other projects.
Deployment deploy: copy the final package to a remote warehouse for other developers to share with the project
Note: The life cycle is divided into three sets, clean has a single life cycle, so executing mvn -install will not execute clean
2.scope—The scope of dependence
1. Compile, the default value, applies to all stages (development, testing, deployment, and operation). This jar will always exist in all stages.
2. Provided, only used in the development and testing stages, the purpose is to prevent the Servlet container from conflicting with the jar package of your local warehouse. Such as servlet.jar.
3. Runtime, only used at runtime, such as JDBC driver, applicable to the running and testing phases.
4. test, only used during testing, used to compile and run the test code. Will not be released with the project.
5. System, similar to provided, needs to explicitly provide the jar containing the dependencies, and Maven will not look for it in the Repository.
3. Advanced special effects
1. Transitivity
The WebMavenDemo project depends on JavaMavenService1 The JavaMavenService1 project depends on JavaMavenService2
After configuring the dependencies in the pom.xml file, you must first mvn install before the dependent jar packages can be used.
If you want to compile the pom.xml file of WebMavenDemo, JavaMavenService1 must mvn install.
If you want to compile the pom.xml file of JavaMavenService, you must mvn install.
Note: Non-compile dependencies cannot be passed
4.Build
1. Configuration properties
<build>
<!-- 项目的名字 -->
<finalName>WebMavenDemo</finalName>
<!-- 描述项目中资源的位置 -->
<resources>
<!-- 自定义资源1 -->
<resource>
<!-- 资源目录 -->
<directory>src/main/java</directory>
<!-- 包括哪些文件参与打包 -->
<includes>
<include>**/*.xml</include>
</includes>
<!-- 排除哪些文件不参与打包 -->
<excludes>
<exclude>**/*.txt</exclude>
<exclude>**/*.doc</exclude>
</excludes>
</resource>
</resources>
<!-- 设置构建时候的插件 -->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<!-- 源代码编译版本 -->
<source>1.8</source>
<!-- 目标平台编译版本 -->
<target>1.8</target>
</configuration>
</plugin>
<!-- 资源插件（资源的插件） -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>compile</phase>
</execution>
</executions>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<!-- war插件(将项目打成war包) -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<!-- war包名字 -->
<warName>WebMavenDemo1</warName>
</configuration>
</plugin>
</plugins>
</build>
2.Flatten Maven Plugin
Scenario: Modular applications developed using maven can be released for others to use, such as various open source libraries. When used, they are either inherited or introduced in the form of dependencies. However, when we look at the pom.xml files of various libraries, they are usually relatively simple, and generally only have some necessary dependency information. As a developer, we usually think that users also need this information. However, during real development, the pom of the corresponding module may be more complicated. It may use various plug-ins, reference various dependencies, inheritance relationships between components, and even take different branches according to different parameters, that is, use the profile mechanism, etc., maven defaults to When deploying, all information about the pom in the corresponding module will be kept and will not be changed. This will bring some trouble to the release of the module. If you directly release such pom.xml, it may cause interference to users, and it is difficult to locate a problem if there is a problem.
Function: Generate a compressed version of pom.xml file
Elements related to construction will be deleted;
elements related to development will be deleted by default;
only some information necessary for the user of the component will be included;
variables will be parsed;
superior relations will be parsed, and then compressed and deleted;
actual use during construction The profile will be evaluated and processed as appropriate;
the profile driven by the JDK or OS will be retained, and dependencies can be dynamically controlled when needed.