Today’s sharing started, please give us more advice ~

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.

Transitivity depends on discovery

  • A fairly common situation, such as A being dependent on other libraries B. If another project C wants to use A, then project C also needs to use library B.

  • Maven avoids the need to search all required libraries. Maven reads project files (POM.xml) to find out the dependencies between their projects.

  • All we need to do is define the direct dependencies in each project’s POM. Maven will take care of the rest.

1. First create an empty project in IDEA

2. After the ideaWorkspace empty project is created, in the empty project space, click New Module

Create module ebuy-2 again as above:

3. Maven project dependencies

3.1. Simply put, even projects can depend on each other and use each other’s JAR packages to depend on files.

For a simple example, introduce dependency files in project ebuy-1 and reference project ebuy-1 in project ebuy-2.

3.2. Simply test whether mysql driver dependencies are available in ebuY-2

In this case, the ebuy-2 project references the ebuy-1 project, and the ebuy-1 project relies on the mysql driver package, so it is displayed in the ebuy-2 project. After testing, cbuy-2 can use the referenced mysql driver.

3.3. Cross-project tool class references

3.4. Scope of Maven dependency control

Scope tag parameters are as follows:

  • Compile: The dependency scope (the default), which is valid for compiling, testing, and running all three classpath types, i.e. the jar package is used for compiling, testing, and running;

  • Test: Test dependency scope. This dependency scope can only be used to test the classpath, and cannot be used when compiling and running the project. Typically, JUnit is only needed when compiling and running the test code.

  • Provided: This dependency scope is valid for compile and test classpath, but not for runtime;

  • Runtime: Runtime dependency scope, valid for testing and running the classpath, but not for compiling main code, typically JDBC driver implementations (which are rarely used);

The optional tag parameters are as follows:

  • True indicates that jar packages under this item cannot be referenced, but the project can still be referenced and its utility classes are not restricted.

  • False indicates that jar packages under this item can be referenced, but the project can still be referenced and its utility classes are not restricted.

Scope defaults to compile

Optional Defaults to false

3.5. Maven dependency exclusion

In project references, we typically create all the JAR packages and utility classes in one project, which is then referenced by other projects, which is equivalent to calling. However, sometimes we need to use a higher version of a jar package in another project, and then the jar package from the reference project is not applicable. We need to import the higher version of the dependency file ourselves, and then exclude the jar package from the original reference project.

The demo is as follows:

4. Maven Project Inheritance (recommended)

4.1. Parent Inheritance

Note:

This inheritance will be used a lot (and a lot) by aggregation engineering in future actual development projects.

4.2 Introduction to Use of dependencyManagement

The dependencyManagement element in Maven provides a way to manage dependency version numbers. If you declare the version number of the dependent JAR package in the dependencyManagement element (that is, in the parent project), all child projects re-introduce the dependent JAR package without explicitly listing the version number, only listing the required dependencies. Maven looks for dependencyManagement up the parent-child hierarchy

Element, and then use the version number it specifies.

4.3 Example Demonstration:

In the parent project ebuY-1:

In subproject ebuY-2:

If we enter the version number of the dependency in the subproject:

4.4. Advantages

If you have multiple subprojects that reference the same dependency, you can avoid declaring a version number in each used subproject. When you want to upgrade or switch to another version, you only need to update in the top parent container, not modify the child projects one by one; In addition, if a subproject needs another version, you only need to declare version, and the version in the parent project will be automatically overwritten.

4.5 matters needing attention

DependencyManagement defines only a dependency declaration and does not implement import, so subprojects need to explicitly declare required dependencies.

Today’s share has ended, please forgive and give advice!