Maven is a project management tool that contains an object model. A set of standards, a dependency management system. And are used to run the plug-in goals and logic defined in the lifecycle phase.

1. Core functions

Maven’s core function is to properly describe dependencies between projects. In a nutshell, jar packages are obtained through the configuration of the POM.xml file without manually adding jar packages. The essence is to get the JAR package by configuring POM.xml.

2. What problems can Maven solve

  1. Construction engineering,
  2. Management of the jar,
  3. Compile the code,
  4. Automatically run unit tests,
  5. packaging
  6. Generate reports,
  7. Deploy the project and generate the Web site.

3. The maven repository

A Maven repository is a third-party library that a project relies on. The repository is located in a location called a repository. A repository is a place where jar packages are stored. Warehouse is divided into: local warehouse, third party warehouse, central warehouse

  • Local: The local repository is not created after Maven is installed, it is created the first time Maven commands are executed. Used to store plug-ins and JARS downloaded from remote or central repositories, the default location of the local repository is user.dir/.m2/repository
  • Remote: also known as third party warehouse, internal central warehouse and private server. Private servers, generally by the companies themselves, only to share the company internal use, it can be as the company’s internal build collaboration and the archive, as a public library image cache, reduce the external access and download the frequency of using private servers in order to reduce the access to the central warehouse servers is a local area network (LAN), it can use the central warehouse must use the network. Companies create third-party repositories to make sure that when a project is being developed, all the JARS needed for the project come from that repository, so that everyone’s version is the same. Note: Connect private server, need to be configured separately. If no private server is configured, it is not used by default
  • Central: repo1.maven.org/maven2 The Maven central repository is maintained by the Maven team itself and contains a very full set of JARS containing most of the popular open source Java artifacts. Using this repository, developers can search all available code libraries.

How to get jars: The project uses some plug-ins or jars, and when we execute Maven build commands, Maven starts looking for dependent libraries in the following order

  1. If no, go to Step 2. If no, perform other operations.
  2. Search in the central repository. If it cannot be found and one or more remote repositories have been set up, perform Step 4. If found, download to the local repository for future reference.
  3. If the remote repository is not set up, Maven will simply stall processing and throw an error (the dependent file cannot be found).
  4. Search one or more remote repositories for the dependent files, and if found, download them to the local repository for future reference, otherwise Maven will stop processing and throw an error (the dependent files cannot be found).

4. Common maven commands

5.Maven dependency management

A core feature of Maven is dependency management. When we deal with multi-module projects (consisting of hundreds or thousands of modules or subprojects), the dependencies between modules become very complex and difficult to manage. Maven provides a highly controlled approach to this situation. The Maven project does not import jar packages directly into the project, but by adding the coordinates of the required JAR packages to the POM.xml file. In this way, when you need to reference jar packages, you only need to look up the POM. XML file, and then through the coordinates in pom. XML, go to a warehouse specially used to store JAR packages according to the coordinates to find these JAR packages, and then run these JAR packages. All we need to do is define the direct dependencies in each project’s POM. Maven will take care of the rest. I have to say that there is A fairly common situation where A is dependent on other libraries B. If another project C wants to use A, then project C also needs to use library B. This leads to dependency passing, which leads to dependency version conflicts!

POM label daqo, www.runoob.com/maven/maven…

6. How to resolve dependency version conflicts in Maven — in four ways

First declaration priority: Define dependencies in the POM.xml file, benchmarking against the dependencies defined first

<dependencies> <! -- spring-beans-4.24. -->
  	<dependency>
  		<groupId>org.springframework</groupId>
  		<artifactId>spring-context</artifactId>
  		<version>4.2.4. RELEASE</version>
  	</dependency><! -- spring-beans-3.0. 5 -->
  	<dependency>
  		<groupId>org.apache.struts</groupId>
  		<artifactId>struts2-spring-plugin</artifactId>
  		<version>2.3.24</version>
  	</dependency>
</dependencies>
Copy the code

Second, the shortest path priority principle: That is, when we add the spring-bean dependency separately to the pop.xml file and the Struts-spring-plugin depends on the spring-bean, the Struts-spring-plugin is the same as the spring-bean we define separately. A separately defined bean dependency is therefore benchmarked

<dependency>
  	<groupId>org.springframework</groupId>
  	<artifactId>spring-beans</artifactId>
  	<version>4.2.4. RELEASE</version>
</dependency>
Copy the code

Struts2-spring-plugin excludes internal JAR dependencies on spring-beans when specifying the struts2-spring-plugin version

<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>
Copy the code

4, version locking principle: in the face of many dependencies, version locking this way does not need to consider the dependent path, declaration optimization and other factors, can directly lock the version of the dependent JAR package, locking does not consider the declaration sequence and path.

<properties>
	<spring.version>4.2.4. RELEASE</spring.version>
	<hibernate.version>5.0.7. The Final</hibernate.version>
	<struts.version>2.3.24</struts.version></properties> <! -- Locked version, struts2-2.324., spring42.4., hibernate5. 07. -->
<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
			<version>${spring.version}</version>
		</dependency>
        </dependencies>
</dependencyManagement>
Copy the code

Jar package conflict resolution

Maven projects can cause conflicts when importing dependencies because they refer to different versions of jars. Jar conflicts are generally harmless, but some can cause projects to fail to start. The first thing to do is read the log! Typically, the log will tell you which package has a problem. If there is no obvious message in the log, compare the package referenced by the current version of the code with the previous version to make it clear. Common JAR conflicts (log4j vs. SLf4J, FastJSON vs. Jackson, Log4j vs. SLf4j, etc.)

Reference: blog.csdn.net/pjh88/artic…