What is Maven
1. An automated construction tool for the Java platform
2. Build
● Use source files, configuration files, page files, static files and other resources as raw materials to generate a runnable project
● A BS project finally runs the compilation result of the Web project (composed of class bytecode files)
3. The link of construction
● Clean: completely delete the previously compiled bytecode file
● Compile: compile the source code into a bytecode file
● Test: automatically call the test program of junit
● Package: Type the project into jar or war according to the specified packaging method
● Install: install the successfully packaged jar or war to the specified location in the warehouse (local warehouse)
Maven configuration
下载maven3.3.9：http://archive.apache.org/dist/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.zip
1. Check the environment variable configuration of JDK
2. Unzip the downloaded file to a non-Chinese path directory
3. Configure Maven environment variables
● The variable name can be MAVEN_HOME or M2_HOME //M2_HOME is a compatible configuration method
4. Check the configured Maven version: mvn -v
Maven example
1. Introduction to Maven Project
① Conventional directory structure
Hello project name
|---src source code
|---|---main stores the main program
|---|---|---java stores Java source files
|---|---|--- resources store other configuration files
|---|---test store test programs
|---|---|---java
|---|---|---resources
|---pom.xml Core configuration file
② Reasons for agreeing on the directory structure
● Maven needs to know where the source files are stored in order to compile and package
● Follow the convention that the configuration is greater than the configuration, and the configuration is greater than the code specification
2. Create a Maven project
● Create a simple java class: D:\Hello\src\main\java\com\test\maven\Hello.java, the content is as follows:
package com.test.maven;
public class Hello {
public String sayHello(String name){
return "Hello "+name+"!";
}
}
● Create a simple java test class: D:\Hello\src\test\java\com\test\maven\HelloTest.java, the content is as follows:
package com.test.maven;
import org.junit.Test;
import static junit.framework.Assert.*;
public class HelloTest {
@Test
public void testHello(){
Hello hello = new Hello();
String results = hello.sayHello("litingwei");
assertEquals("Hello litingwei!",results);
}
}
● Create a new pom.xml file: D:\Hello\pom.xml, the content is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<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>
<artifactId>Hello</artifactId>
</project>
3. Several basic commands
● mvn clean
● mvn compile compile the main program
● mvn test-compile compile test program
● mvn test
● mvn package
● mvn install to the local warehouse
4. About networking
● The functions after executing the command basically have to be completed by specific plug-ins, and Maven itself does not include these plug-ins
● Maven will first go to the local warehouse to find out whether the plugin exists (the default location of the local warehouse is the repository folder under the .m2 folder under the current user path), and you can modify the location of the local warehouse as needed (enter the Maven installation directory) In the conf folder, edit the settings.xml file and modify the configuration <localRepository> <custom repository location> </localRepository>)
● If you cannot find the plug-in or other module you need in the local warehouse, you need to go online to find it in the central warehouse. When the network cannot be connected or the required plug-in or other module resources cannot be downloaded from the central warehouse, the build fails
5. Compile
Enter the Hello directory and execute the compile command: mvn compile
POM
POM (Project Object Model): Project Object Model
The pom.xml file is the core configuration file of the Maven project, which can configure all operations related to the build process
coordinate
The coordinates in Maven are to locate the only Maven project by using three vector dimensions
● groupid: generally adopt the method of company or organization domain name + project name in reverse order
● artifactid: generally use the project's module name
● version: specify the version
warehouse
● Warehouse type
Local warehouse: the warehouse on the current computer, serving all the Maven projects on the current computer
Remote warehouse:
Private server (equivalent to an intermediary, mainly used when not all computers can be connected to the Internet)
Central Warehouse: Serving Maven projects around the world
Central warehouse mirroring: share the pressure of the central warehouse
● The contents of the warehouse are saved in the form of a Maven project
Plugins needed by Maven itself
Third-party jar package
Self-developed Maven project
Life cycle
The most important lifecycle: the default lifecycle, including compilation, testing, packaging, installation, and deployment. No matter which command is executed, Maven will execute it from the initial step to the command.
Each stage of the life cycle only defines what the task is to be performed, and each stage has a corresponding plug-in, which is completed by a specific plug-in
Use IDE tools (here eclipse is used)
1. Create a Maven Java project
Edit the setting.xml file, find the profiles tag, and add the following configuration to specify the specific version of JDK
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
Right-click the pom.xml file and select as follows:
input the command:
Similar procedures for other commands
2. Create a Maven Web project
The creation process is the same, but the war package is finally marked
But the Web project created in this way does not have the most critical deployment descriptor of web.xml, so it needs to be modified:
● Right-click the project name == "Select properties
● Select project facets == "Find dynamic web module ==" on the right, uncheck, then apply == "check again
● Edit the information and specify the location where web.xml is stored
The completed Web project structure diagram is as follows:
rely
1. Compile's dependency range (the widest range, the default dependency range)
● Effective for the main program
● Effective for testing procedures
● Participate in packaging
● Participate in deployment
● Typical: spring-core.jar
2. Dependency range of test
● Invalid to the main program
● Effective for testing procedures
● Do not participate in packaging
● Not participating in deployment
● Typical: junit
3. Scope of provided dependency
● Effective for the main program
● Effective for testing procedures
● Do not participate in packaging
● Not participating in deployment
● Typical: servlet-api.jar
ps: The scope of dependence requires special attention not to depend on errors, otherwise it may report some very strange errors for which no reason can be found
4. Transmission of dependencies
When a project introduces a dependency, it happens that the dependency also depends on other jars, then this other jar will also be dependent on the current project together, which is the transfer of dependencies
ps: jar dependencies in the non-compile domain cannot be passed
5. Exclusion of dependence
The exclusion of dependencies is just the opposite concept to the transfer of dependencies. When a dependency is passed, it conflicts with the existing jar or conflicts occur due to inconsistent versions among multiple dependencies. Pass through
use
<exclusion>
<groupId></groupId>
<artifactId></artifactId>
</exclusion>
Label to exclude
ps: If the dependencies excluded by the A project are in the middle layer, when other projects depend on the A project, the excluded dependencies will not be passed on.
6. The principle of dependence
In order to solve the conflict between jar packages, Maven's dependency has the following principles:
● Project B depends on Project A, and a dependent version of Project A is passed down. Project B happens to have this dependency and the version is 1.2. At this time Project C depends on Project B, then the corresponding version in Project C The dependent version is 1.2 //Principle 1: The shortest path takes precedence
● Project A (version 1.1 on which z depends), Project B (version 1.2 on which z depends), and Project C depends on project A and Project B at the same time. At this time, if Project C declares to depend on Project A in the pom.xml file, then The version of the z dependency is 1.1; and if the C project first declares the B project in the pom.xml file, the corresponding version of the z dependency is 1.2 //Principle 2: When the paths are the same, the first declaration takes precedence
7. Unified management of dependencies
Scenario: a unified version upgrade is required for certain dependent versions
● Use custom tags to declare version information in the <properties></properties> tag, and use ${ custom tags } to reference the declared version information on dependencies that require a specified version.//So if you want to modify the version information uniformly, Just modify the corresponding version information in the <properties> tag
● The same effect can be achieved using the form of the parent project
Maven inheritance
Scenario: z dependency can be junit (the reason is that the scope of junit is test, and dependency transmission cannot be carried out, so junit will be scattered in different engineering modules, which may cause different versions of the project)
The version of Z dependency of A project is 4.0
The version of Z dependency of project B is 4.0
The version of the Z dependency of the C project is 4.9
Solution: Create a parent project (packaging method is pom), specify the specific version, do not specify the version when referencing the z dependency in the subproject, and hand it over to the parent project for unified version management //The relationship between the subproject and the parent project is inheritance Relationship
Parent project:
After the dependency management is configured, the subproject will not really depend on the dependencies configured by the parent project, but when the subproject needs a dependency, you can directly configure the groupId and artifactId tags in the pom.xml file
Subproject:
Maven aggregation
Convenient to build, just build a parent project to completely build all sub-projects
The pom.xml file configuration in the parent project is as follows:
ps: Maven's central warehouse: https://mvnrepository.com/
Finish!