Maven learning notes (1): Maven coordinates and dependencies, maven learning notes

Maven learning notes (1): Maven coordinates and dependencies, maven learning notes

Maven was introduced to the company and soon became fascinated by the features that Maven does not need to manually copy numerous jar packages to the project. As I am new to this technology, if there is a mistake in my notes, I hope haihan can correct me.

 

Maven has five coordinate elements:

-- GroupId: used to specify the project name, such as com.163.blog (for example, do not care if there is any such thing), indicating Netease's blog Project

-- ArtifactId: used to specify the name of a specific module under the project, such as blog-security, indicating the user security authentication module under the blog project.

-- Version: used to specify the version of the module specified by artifactId, such as 0.0.1-SNAPSHOT. (The version has many things that the landlord has not learned yet)

-- Packaging: Specifies the packaging method of this Maven project, that is, the type of the package output after executing the mvn package. The default value is jar, and can also be set to war.

-- Classfier: used to create ancillary builds for this Maven project, such as blog-security-2.0.0-javadoc.jar, blog-security-2.0.0-src.jar, etc.

 

Among the five elements, the first three (groupId, artifactId, version) elements must be specified, just like the mailing address we entered during the delivery, maven can only find the corresponding dependency package by analyzing these three elements. The name of the package generated after executing the mvn package command is usually in the format of artifactId-version [-classfier]. packaging.

 

For Maven dependencies, I personally feel that it is relatively simple. However, in actual development, it may be most difficult to troubleshoot dependency conflicts.

Maven uses the <dependencies> label in the pom file to specify the dependency set, and the sub-label <dependency> to specify the specific dependency. The specified dependency has many elements:

-- GroupId: Same as above

-- ArtifactId: Same as above

-- Version: Same as above

-- Type: specifies the type of the dependent file, that is, the extension name of the dependent package, such as jar and war.

-- Scope: Specifies the dependency scope of the dependent file, that is, where the dependent file can act.

-- Compile: This range includes compiling, testing, and running [such as spring-core]

-- Test: only dependent on the package during project testing [such as jUnit]

-- Runtime: The program package is dependent on the program during project testing and running. It does not depend on the program during compilation. That is, the project cannot use the function of the program package during compilation. [For example, JDBC driver]

-- Provided: the package is dependent on the package during compilation and testing, and does not depend on the package during runtime. [for example, servlet-api] packages are not dependent because web containers are provided.

-- System: this is a high-end scope. I don't understand what can be done in actual development.

-- Option: Specifies whether the dependency is an optional dependency. The optional dependency is not transmitted during dependency transmission.

-- Exculsions: Because the passing dependency exists, you can use the sub-tag <exculsion> to exclude the passing dependency.

 

The concept of pass-through dependency is relatively simple, that is, project A requires Project B's support and project B requires Project C's support, so A is the first direct dependency for Project B, B is directly dependent on C, and C is the transmission dependency of. In short, the father depends on his grandfather and his son depends on his father. If he wants to form a complete three generations, his son is the transmission dependency of his grandfather.

 

The passed dependency is also a dependency, but it is passed. Therefore, the transmission dependency also has the dependency scope.

-- When the second direct dependency scope is compile, the dependent scope of the passed dependency is the same as that of the first direct dependency.

-- When the second direct dependency range is test, the passed dependency will not be passed.

-- When the second direct dependency scope is provided, it is passed only when the first direct dependency is provided, and the dependency scope is the same.

-- When the second direct dependency scope is runtime, the dependent scope of the passed dependency is the same as that of the first direct dependency. Except when the first direct dependency is compile, the scope of the passed dependency is runtime.

 

Since we cannot fully understand all the passed dependencies of the explicitly dependent package, this may cause the following problems:

Dependency 1: A --> B --> C (1.0)

Dependency 2: D --> E --> C (2.0)

Since dependency 1 and dependency 2 both have a pass-through dependency C, and the C version is different, which version does Maven use to parse? In this case, the parsing policy used by Maven gives priority to Declaration, that is, the declared dependency's passed dependency will be parsed, and the declared dependency's passed dependency will not be parsed.[Statement priority]

Another situation is as follows:

Dependency 1: A --> B --> M --> C (1.0)

Dependency 2: D --> E --> C (2.0)

Because the path length of dependency 1 depends on C is 3, and the path length of dependency 2 is 2, Maven will parse the dependency 2.[Path first]

 

When declaring a dependency, use the <optional> element to set whether the dependency is optional. If it is set to true, the dependency is optional, as shown below:

A --> B (1.0)

A --> B (2.0)

A depends on B, but B has two versions. During configuration, you can configure two versions of B as optional dependencies, and select to use A dependency when using B. Of course, this method is not scientific, so there is basically no need to configure optional dependencies, and optional dependencies will not be passed. Object-oriented thinking emphasizes a single responsibility rather than a hodgedge, so the optional dependency configuration is totally different from the OOP idea.

 

One of the artifacts in Maven dependency is to exclude dependencies. For example, A depends on B and B depends on C's 2.0 version. But now the project needs to use C's 4.0 version. Due to the dependency passing, version 2.0 of c will be parsed by Maven. Therefore, I can exclude version 2.0 of C and explicitly declare version 4.0 dependency of C.

Declaration example for removing Dependencies

 1 <dependencies> 2     <dependency> 3         <groupId>com.163.blog</groupId> 4         <artifactId>blog-security</artifactId> 5         <version>4.0.0</version> 6         <exclusions> 7             <exclusion> 8                 <groupId>com.qq.im</groupId> 9                 <artifactId>project-a</artifactId>10             </exclusion>11         </exclusions>12     </dependency>13 </dependencies>

You only need to specify the groupId and artifactId of the dependency to be excluded, because the two elements can fully describe a dependency during dependency transmission. That is, in Maven-parsed dependencies, it is impossible to have multiple dependencies with the same groupId and artifactId, but different versions.

 

Finally, for dependency optimization, many dependencies are implicitly added to the project because of the dependency passing. In this case, you can execute mvn dependency: list to list all dependencies and use mvn dependency: tree allows you to view the relational tree structures of all dependencies. Using mvn dependency: analyze can analyze which dependencies in the project are used but are not explicitly declared, and those dependencies are explicitly declared but not used.

 

Maven dependency problems

It is manually added one by one and can be written in the parent pom. sub-projects can directly drink the parent pom, which is also convenient for management.
Even if the jar package has its own dependency, you may write the dependency of a jar package. Other jar packages may be automatically downloaded during compilation.

Dependency issues in pomxml in maven

The dependency can be found automatically, but only available in the source. Solution: The above already exists. You can also add a source to solve the problem.