YouTip

Maven's core feature is dependency management. When dealing with multi-module projects (containing hundreds or thousands of modules or sub-projects), the dependency relationships between modules become very complex and difficult to manage. In such cases, Maven provides a highly controlled approach. * * * ## Transitive Dependency Discovery A fairly common situation, for example, where A depends on other library B. If another project C wants to use A, then project C also needs to use library B. Maven can avoid the need to search for all required libraries. Maven reads the project file (pom.xml) to find the dependency relationships between their projects. All we need to do is define the direct dependency relationships in each project's pom. Maven will handle the rest. Through transitive dependencies, the graph of all included libraries can grow rapidly. When there are duplicate libraries, the possible situations can continue to increase. Maven provides some features to control the degree of transitive dependencies. | Feature | Feature Description | | --- | --- | | Dependency Mediation | Determines which dependency version will be used when multiple manually created versions appear at the same time. If two dependency versions are at the same depth in the dependency tree, the first declared dependency will be used. | | Dependency Management | Allows you to directly specify a manually created version for use. For example, suppose project C contains project B as its dependency, and project B depends on project A. In this case, you can explicitly specify the version of project A to be used when project B is referenced. This means you can control which specific version of project A will be used by project B. | | Dependency Scope | Dependencies included in each phase of the build process. | | Dependency Exclusions | Any transitive dependency can be excluded through the "exclusion" element. For example, A depends on B, B depends on C, so A can mark C as "excluded". | | Dependency Optional | Any transitive dependency can be marked as optional by using the "optional" element. For example: A depends on B, B depends on C. Therefore, B can mark C as optional, so that A can no longer use C. | * * * ## Dependency Scope Transitive dependency discovery can be limited by using the following dependency scopes: | Scope | Description | | --- | --- | | compile | This scope indicates that the dependency is only valid in the project's classpath. Default value. | | provided | This scope indicates that the dependency is provided by the runtime JDK or web server. | | runtime | This scope indicates that the dependency is not required during the compilation phase but is required during the execution phase. | | test | This scope indicates that the dependency is only in the test compilation phase and execution phase. | | system | This scope indicates that you need to provide a system path. | | import | This scope is only used when the dependency is a dependency defined in a pom. Meanwhile, the dependency relationships defined in the part of the current project's POM file can replace a specific POM. | * * * ## Dependency Management Under normal circumstances, in a common project, there is a series of projects. In this case, we can create a pom file for common dependencies, which contains all the common dependency relationships. We call it the pom parent of other sub-project poms. The following example can help you better understand this concept. !(#) The following is the detailed description of the dependency graph above: The pom.xml file for App-UI-WAR is as follows: 4.0.0com.companyname.groupnameApp-UI-WAR1.0warcom.companyname.groupnameApp-Core-lib1.0com.companyname.groupnameApp-Data-lib1.0 The pom.xml file for App-Core-lib is as follows: Rootcom.companyname.groupname1.04.0.0com.companyname.groupnameApp-Core-lib1.0jar The pom.xml file for App-Data-lib is as follows: Rootcom.companyname.groupname1.04.0.0com.companyname.groupnameApp-Data-lib1.0jar The pom.xml file for Root is as follows: 4.0.0com.companyname.groupnameRoot1.0pomcom.companyname.groupname1Lib11.0com.companyname.groupname2Lib22.1com.companyname.groupname3Lib31.1 Now when we build the App-UI-WAR project, Maven will traverse the dependency graph to find all dependencies and build the application. Through the above example, we can learn the following key concepts: * Common dependencies can be grouped together using the concept of a pom parent. The dependencies of App-Data-lib and App-Core-lib projects are listed in the Root project (refer to Root's packaging type, which is a POM). * There is no need to declare Lib1, lib2, Lib3 as dependencies in App-UI-W. Maven implements this detail through the transitive dependency mechanism.