Maven's (ix) dependency relationship

In MAVEN's management system, each project constitutes a complex network of relationships, but each project is equal, a world without distinction and equality, and every project in the world can theoretically be interdependent. That is, you are on an equal footing with the developers of spring, your project can depend on the spring project, and the spring project can also depend on your project (although it is unlikely to happen in the real world, you daotie the money others dare not quote).

The dependencies of the project are divided into three main types: dependency, inheritance, aggregation

Dependent relationships

Dependencies are one of the most common, and your projects need to rely on other projects, such as Apache-common packages, spring packages, and so on.

<dependency>               <groupId>junit</groupId>               <artifactId>junit</artifactId>               <version>4.11</version>               <scope>test</scope>               <type >jar</type >               <optional >true</Optional > </dependency>

Any external dependency description includes the following elements: GroupId, Artifactid, version, scope, type, optional. The first 3 of them are necessary.

The version here can be represented by an interval expression, such as (2.0,) representing >2.0,[2.0,3.0), which means that 2.0<=ver<3.0; multiple conditions are separated by commas, such as [1,3],[5,7].

The type usually occurs when the POM reference is dependent and is not used at other times.

Maven argues that the dependencies of the program vary with the program's phase and application scenario, so the dependencies in Maven have scope (scope) limitations. In Maven, scope contains the following values:

Scope options
Compile (compilation scope)	Compile is the default scope , and if a scope is not provided, the scope of the dependency is the compilation scope. Compilation scope dependencies are available in all classpath, and they are also packaged.
Provided (range provided)	Provided dependencies are only used when the JDK or a container has provided the dependency. For example, if you develop a Web application, you might need the Servlet API available in the compilation Classpath to compile a servlet, but you do not want to include the Servlet API in the packaged war, the Servlet API The jar is provided by your application server or the servlet container. A dependency that has been provided for scope is available at compile classpath (not at runtime). They are not transitive and will not be packaged.
Runtime (Runtime Range)	Runtime relies on the need to run and test the system, but it is not required at compile time. For example, you might only need the JDBC API JAR when compiling, and only the JDBC driver implementation is required when running.
Test (Testing range)	Test range dependencies are not required at compile and run time, and they are available only during the test compilation and test run phases.
System (systems-wide)	System-wide dependencies are similar to provided, but you must explicitly provide a path to the jar file in the local system. This is done to allow compilation based on local objects, which are part of the System class library. Such artifacts should always be available, and MAVEN will not look for it in the warehouse. If you set a dependency scope to a system scope, you must provide a SYSTEMPATH element at the same time. Note that this range is deprecated (you should always try to reference dependencies from a public or custom Maven repository).

The type in dependency is typically not configured, and the default is the jar. When type is pom, the reference relationship is represented:

<dependency>     <groupId>org.sonatype.mavenbook</groupId>     <artifactId> persistence-deps</artifactid>     <version>1.0</version>     <type>pom</type> </dependency>

At this point, the project imports all the jar packages of persistence-deps into the dependent libraries.

You can create a packaging method for the POM project to put some common dependencies together for direct reference to other projects, and don't forget to specify a dependency type of pom (<type>pom</type>).

Inheritance relationship

Inheritance is the avoidance of repetition, as is the case with Maven's inheritance, which has the added benefit of making the project more secure. An inheritance relationship occurs when there is a subordinate relationship between projects.

The parent project is configured as follows:

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.clf.parent</groupId> < Artifactid>my-parent</artifactid> <version>2.0</version> <packaging>pom</packaging > <!--dependencies under this node will automatically inherit all of the quilt items--<dependencies> <dependency> <groupid>org. Slf4j</groupid> <artifactId>slf4j-api</artifactId> <version>1.7.7</ version> <type>jar</type> <scope>compile</scope> </depend Ency> </dependencies> <dependencyManagement> <!--dependencies under this node are only for a uniform version number, and will not be automatically inherited by quilt items unless the child project Active referencing, the benefit is that the subproject can be used without writing the version number-<dependencies> <dependency> <groupid>org.spri Ngframework</groupid> <artifactId>spring-orm</artifactId> <version>4 .2.5.release</version>            </dependency> <dependency> <groupid>org.springframework</groupi D> <artifactId>spring-web</artifactId> <version>4.2.5.release</versi on> </dependency> <dependency> <groupid>org.springframework</ Groupid> <artifactId>spring-context-support</artifactId> <version>4.2.5 . release</version> </dependency> <dependency> &LT;GROUPID&GT;ORG.SPR Ingframework</groupid> <artifactId>spring-beans</artifactId> &LT;VERSION&G t;4.2.5.release</version> </dependency> </dependencies> </dependencymanagemen T> <!--This element is similar to Dependencymanagement, which is used for plug-in management--<pluginManagement> ... &lt ;/pluginmanagement>&Lt;/project> 

Note that at this point <packaging> must be pom.

In order for the project to run correctly, you must make all of the child projects use a consistent version of the dependencies, and you must ensure that the dependencies and versions of each project are applied consistently to ensure that the same results are tested and published.

Maven uses the Dependencymanagement element to provide a way to manage dependent version numbers. The dependencymanagement element is typically seen in the parent pom at the top level of an organization or project. Using the Dependencymanagement element in Pom.xml allows all references to a dependency in a subproject without explicitly listing the version number. Maven walks up the parent-child hierarchy until a project with the dependencymanagement element is found, and then it uses the version number specified in the Dependencymanagement element.

The parent project relies on the dependencies Declaration, and the subproject is automatically inherited from all . The parent project in Dependencymanagement only declares dependencies and does not implement the introduction, so the subproject needs to display a dependency on the declaration that needs to be used. If you do not declare a dependency in a subproject, it is not inherited from the parent project, the item is inherited from the parent project only if the dependency is written in the subproject, and version and scope are read from the parent pom In addition, if the version number is specified in the subproject, The jar version specified in the subproject is then used.

If a project needs to inherit the parent project, the underlying configuration should look like this:

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.clf.parent.son</groupId> <artifactId>my-son</artifactId> <version>1.0</version> <!--Declare the coordinates of the parent project--<parent&  Gt <groupId>org.clf.parent</groupId> <artifactId>my-parent</artifactId> <version>2.0 </version> <!--relative path to the Pom.xml file for the parent project. Relative paths allow you to select a different path. -<!--default value is: /pom.xml. Maven first looks for the Pom of the parent project where the current project is being built, and <!--next in this location in the filesystem (RelativePath location), and <!--then in the local repository and finally in the remote warehouse looking for the parent project's POM. --<relativepath> /parent-project/pom.xml</relativepath> </parent> <!--Declare the dependency of the parent project Dependencymanagement, without writing the version number--and &LT              ;d ependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> </dependency> <dependency> &lt ; groupid>org.springframework</groupId> <artifactId>spring-beans</artifactId> </dependency> &LT;/DEP Endencies> </project>

Aggregation relationships

With the rapid development of technology and the requirements of various types of users more and more high, the software itself is becoming more and more complex, and then the software designers began to use a variety of ways to develop, so there is our layered architecture, sub-module development, to improve code clarity and reuse. For this feature, MAVEN also gives the appropriate configuration.

MAVEN's multi-module management is also very powerful. In general, MAVEN requires that all modules of the same project be placed in the same directory, and each subdirectory represents a module, such as

Total Items/

Pom.xml Pom profile for total project

Sub-Module 1/

Pom.xml the Pom file for sub-module 1

Sub-Module 2/

Pom.xml the Pom file for sub-module 2

The overall project is configured as follows:

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.clf.parent</groupId> <artifactId>my-parent</artifactId> <version>2.0</version> <!--packing class        Type must be pom--<packaging>pom</packaging> <!--the direct sub-module of the project is declared--<modules> <!--here is not artifactid, but the directory name of the module--<module>module-1</module> <module>modul E-2</module> <module>module-3</module> </modules> <!--aggregation is also a parent-child relationship, the de in the total project Pendencies and Dependencymanagement, pluginmanagement usage and inheritance are similar--<dependencies> ... </depen Dencies> <dependencyManagement> ... </dependencyManagement> <plugin Management>. </pluginManagement></project>

The sub-modules are configured as follows:

<project>        <modelVersion>4.0.0</modelVersion>        <groupid>org.clf.parent.son</ groupid>        <artifactId>my-son</artifactId>        <version>1.0</version>       <!-- Declares the coordinates of the parent project-       <parent>              <groupId>org.clf.parent</groupId>               <artifactId> my-parent</artifactid>               <version>2.0</version>        </parent></project>

The relationship between inheritance and aggregation

First, inheritance and aggregation belong to the parent-child relationship, and the packaging of the parent pom in the aggregate pom and the inheritance relationship are POM.

The difference is that for an aggregation module, it knows which modules are aggregated, but those that are aggregated do not know the existence of this aggregation module. For the parent pom of an inheritance relationship, it does not know which submodules to inherit from it, but those submodules must know what their parent pom is.

In the actual project, a POM is often both a pom and a parent pom, it inherits a project, itself contains several sub-modules, and there will certainly be a common dependency, that is, dependency, inheritance, aggregation of the three relationships are coexisting.

The list of Maven inheritable POM elements is as follows:

GroupId: Project group ID, core element of project coordinates;

Version: Project versions, core elements of project coordinates;

Description: Description information of the project;

Organization: Organization information of the project;

Inceptionyear: The founding year of the project;

URL: The URL address of the project

Develoers: Developer information for the project;

Contributors: Contributor information for the project;

Distributionmanagerment: Deployment information for the project;

Issuemanagement: Defect tracking System information;

Cimanagement: Continuous succession information of the project;

SCM: Version control information for the project;

Mailinglistserv: Mailing list information for the project;

Properties: Custom Maven attributes;

Dependencies: Dependency configuration of the project;

Dependencymanagement: Eye-catching dependency management configuration;

Repositories: The warehouse configuration of the project;

Build: Including the project source directory configuration, output directory configuration, plug-in configuration, plug-in management configuration, etc.;

Reporting: Includes the project report output directory configuration, report plug-in configuration, and so on.

Maven's (ix) dependency relationship