Maven's Core Concept
1. coordinates
Maven coordinates consist of main components (GAV) to determine the location of a jar package
groupId: Defines the current Maven organization name
artifactId: Define the actual project name
Version: Defines the current version of the current project
2. Finding coordinates
Visit http://www.mvnrepository.com
3. Dependency management
(1) scope dependency scope, which controls the relationship between dependencies and Classpaths compiled, tested, and run
(2) compile: Default compile dependency range. For compiling, testing, running and packaging, such as struts2-core
(3) test: test dependency range. Testing is required, compiling, running, packaging is not required, such as: junit
(4) Provided: The dependency range has been provided. Compile and test, run and pack. Because the container already provides, for example: jsp-api, servlet-api
(5) runtime: runtime provided. Testing, running and packaging are required, and compiling is not required. For example: jdbc Driver
4. Add jar packages
Add the following code to the pom:
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.9</version> <scope>test</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jsp-api</artifactId> <version>2.0</version> <scope>provided</scope> </dependency> </dependencies>
You will find that the jar package has been added to the project
5. Dependency Transfer
Direct dependence and indirect dependence, test2 depends on test1, test3 depends on test2, test2 directly depends on test1, test3 indirectly depends on test1
When the dependency scope is compile, the dependency can be passed
When the dependency scope is test, dependencies are not passed
6. Optional dependencies
Whether < optional > true/false < optional > is optional can also be understood as whether to pass down. Adding optional to a dependency determines whether the dependency is passed down, not true, and false by default.
7. Resolution of Dependent Version Conflict
(1) Principle of priority of the first declaration
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>4.2.4.RELEASE</version> </dependency> <dependency> <groupId>org.apache.struts</groupId> <artifactId>struts2-spring-plugin</artifactId> <version>2.3.24</version> </dependency>
(2) Priority Principle of Nearest Path, Add jar Packet by Yourself
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>4.2.4.RELEASE</version> </dependency>
(3) Exclusion principle
<dependency> <groupId>org.apache.struts</groupId> <artifactId>struts2-spring-plugin</artifactId> <version>2.3.24</version> <exclusions> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> </exclusion> </exclusions> </dependency>
(4) Version Locking Principle
<properties> <spring.version>4.2.4.RELEASE</spring.version> </properties> <!-- Locked version, spring4.2.4 --> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> </dependencies> </dependencyManagement>
8. Life cycle
Compoile test package install deploy (published to private service)
Three life cycles:
Clean Lifecycle:
Do some cleanup before you do a real build
Default Lifecycle:
Compoile test package install deploy build core parts, compilation, testing, packaging, deployment, and so on
Site Lifecycle:
Generate project reports, sites, publishing sites
(1) Clean Life Cycle: Cleaning Projects
Clean life cycle consists of three stages:
pre-clean performs some work that needs to be done before cleaning clean removes all files generated by the previous build post-clean performs some work that needs to be done immediately after clean
In other words, mvn clean is equivalent to MVN pre-clean
If we run mvn post-clean, then pre-clean and clean will be run.
This is an important Maven rule that greatly simplifies command line input.
(2) Default Life Cycle: Constructing Projects
Default life cycle is the most important one in Maven life cycle, in which most of the work takes place. Here we explain some of the more important and common stages.
validate generate-sources process-sources generate-resources process-resources Copy and process the resource files to the target directory for packaging. compile Compile the source code of the project. process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources Copy and process the resource files to the target test directory. test-compile Compile and test the source code. process-test-classes test Run the test using the appropriate unit test framework. These test codes will not be packaged or deployed. prepare-package package Accept compiled code and package it into a publishable format, such as JAR . pre-integration-test integration-test post-integration-test verify install Install packages into local warehouses to make other projects dependent. deploy Copy the final package to a remote repository for other developers to share with the project
When running any stage, all the previous stages will be run
That's why when we run mvn install, the code is compiled, tested, packaged, and installed in the local warehouse
In addition, Maven's plug-in mechanism is completely dependent on Maven's life cycle, so understanding life cycle is crucial.
(3) Sit life cycle: build project site
Site and site-deploy phases are often used here to generate and publish Maven sites, which are quite powerful features of Maven
Manager likes it better. Documents and statistics are automatically generated. It looks good. We don't have to learn, we'll do it ourselves later.
pre-site performs some work that needs to be done before generating site documents site Generates site Documents for Projects post-site performs some work that needs to be done after the site document is generated and prepares for deployment site-deploy deploys the generated site documents to a specific server
9. model diagram
10. Configure the plug-in to change the jdk version of the project compile
Add the following code to pom.xml
<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.8</source> <target>1.8</target> <encoding>UTF-8</encoding> </configuration> </plugin> </plugins> </build>
Or:
<build> <!-- Many plug-ins are configured --> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.6.1</version> <configuration> <source>11</source> <target>11</target> <encoding>UTF-8</encoding> </configuration> </plugin> </plugins> </build>
Or:
<build> <!-- Many plug-ins are configured --> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.6.1</version> <configuration> <release>11</release> <encoding>UTF-8</encoding> </configuration> </plugin> </plugins> </build>
Or:
<properties> <maven.compiler.source>11</maven.compiler.source> <maven.compiler.target>11</maven.compiler.target> </properties>