Common Maven commands and functions

MVN clean:

Clear the final and intermediate files generated by Maven in the target directory during the build process. The Clean lifecycle can be divided into three sections: pre_clean, clean, and post_clean. By default, Maven only uses the clean section to clear files. If you need to do something before clearing, for example, to count the number and size of target directory files, you can write a Maven plug-in and bind it to the pre_clean stage of the clean lifecycle. The post_clean phase is also true.

 

MVN package:

Package the project. The packaging result is configured in the POM file. In addition to the clean life cycle, Maven has a default life cycle, which is also the core life cycle of Maven. The default life cycle includes validate, compile, test, install, and deploy, some plug-ins that come with Maven are bound respectively. Each time you run an MVN lifecycle command, it starts from validate to the command definition stage. For example, when you execute MVN install, maven has successively executed validate, compile, test, and install. The binding of these lifecycle phases and corresponding plug-ins is set in Maven's root pom, which is transparent to users and can also be customized.

 

MVN clean install-E:

The two lifecycles of Maven are independent of each other and can be used in combination. The preceding command is to clear the target directory before installing the project. -The addition of the-e command prints the error information of Maven command execution on the command line, which facilitates troubleshooting and is very useful.

 

MVN clean install-dmaven. Test. Skip = true-E:

-The dmaven. Test. Skip = true command allows Maven to skip the test stage during lifecycle execution, saving developers time for each build.

 

MVN dependency: analyze-E:

Analyze the dependencies in the project. The output is two lists. The undeclared dependency (indirect dependency) List is used, and the list of unused dependencies is declared. Avoid the information in the first list as much as possible, so that the project cannot be built because the indirect dependency is killed.

Maven dependency management uses the <dependencymanagement> label, which is a dependency pool concept. All dependencies and dependent version information of the entire project should be configured under this label. The dependency configurations required for the Project Sub-project are under the <dependencies> label. The Dependencies under this label are all dependencies defined in the <dependencymanagement> label, and version information is not required.

 

Maven has two rules for indirect dependency Conflict Resolution:

1. shortest Path Principle: A-> b2.0-> c2.0, A-> d1.0-> e1.0-> C3.0. If Project A has the preceding two dependencies, for indirectly dependent C, c2.0 is used because its path is shorter than C3.0.

2. first, configure the principle: A-> b2.0-> c2.0, A-> d1.0-> C3.0. In this case, you need to check the b2.0 configuration and d1.0 configuration location in the POM file, if b2.0 is written in front, c2.0 is used.

 

MVN denpendency: Tree-dincludes = *: JUnit-dverbose:

Analyze the dependency tree of the project and the most common commands for resolving jar package conflicts. When the parameter-dincludes = *: JUnit is added, only the dependent information of the artifactid is printed as JUnit. When the parameter-dverbose is added, the entire process of JUnit dependency is printed.

 

MVN help: valid-POM/MVN help: valid-settings:

The pom file configured in our project is very simple. When Maven needs to use it, it will analyze the POM file in the project and combine it with the root pom file into a real available file. MVN help: the valid-Pom command will print out the available file for troubleshooting. Similarly, MVN help: Valid tive-settings prints the real available configuration files.

 

MVN-T 2 clean install/MVN-T 2C clean install:

Maven supports parallel building.-T 2 indicates that two threads are used for building, and-T 2C indicates that dual-core is used for building.

 

Finally, for the maven version, snapshot is recommended to be used only during the development period. Once it needs to be released online, it should be immediately changed to the official version to avoid inexplicable errors when others build it.