The difference between dependencies and dependencymanagement _maven

There are some jar pack conflicts in the previous project, and many people are not clear about the difference between dependencies and dependencymanagement, which is summed up in this article.

1, depencymanagement application scene

When we have a lot of project modules, we use MAVEN to manage our projects very conveniently, helping us manage the way we build, document, report, rely, SCMS, publish, distribute. It is easy to compile code, rely on management, manage binary library, and so on.

Because we have a lot of modules, we have abstracted another layer, pulling out a itoo-base-parent to manage the public dependencies of subprojects. In order for the project to run correctly, all subprojects must have a unified version of the dependencies, and the dependencies and versions of each project applied must be consistent to ensure that the same results are tested and published.

In the Pom file at the top of our project, we see the dependencymanagement element. The element is used to manage the version of the jar package so that the subproject references a dependent without displaying the version number listed. Maven goes up the parent-child hierarchy until it finds a project with the dependencymanagement element, and then it uses the version number specified in the Dependencymanagement element.

Take a look at the application in our project:

Pom Inheritance diagram:

Dependencies:

Itoo-base-parent (Pom.xml)

[java]  View plain  copy  print? <dependencyManagement>                       <dependencies>                <dependency>                    <groupId>org.eclipse.persistence</groupId>                     <artifactId>org.eclipse.persistence.jpa</artifactId>                    <version>${ org.eclipse.persistence.jpa.version}</version>                    <scope>provided</scope>               </dependency>                                <dependency>                    <groupId>javax</groupId>                    <artifactId> javaee-api</artifactid>                    <version>${javaee-api.version}</version>                </dependency>            </dependencies>       </ dependencymanagement>  

Itoo-base (Pom.xml)

[java]  View plain  copy  print? <!--inherits the parent class-->   <parent>           < artifactid>itoo-base-parent</artifactid>            <groupId>com.tgb</groupId>               <version>0.0.1-SNAPSHOT</version>           < Relativepath> /itoo-base-parent/pom.xml</relativepath>       </parent>           <modelVersion>4.0.0</modelVersion>           <artifactId>itoo-base</artifactId>           <packaging>ejb</packaging>                       <!--Dependency-->            <dependencies>           <dependency>                <groupid>javax</ groupid>               <artifactid >javaee-api</artifactId>           </dependency >                       <dependency>                <groupId>com.fasterxml.jackson.core</groupId>                <artifactId>jackson-annotations</artifactId>            </dependency>                       <dependency>                <groupid>org.eclipse.persistence</groupid >               <artifactId> org.eclipse.persistence.jpa</artifactid>                <scope>provided</scope>            </dependency>       </dependencies>   </ project>  

The benefits of this are the unified management of the project's version number to ensure that the dependencies and versions of the applied projects are consistent to ensure that the same results are tested and published, so that a common dependency is defined in the top-level pom. You can also avoid declaring a version number in each of the subprojects that you use, so that when you want to upgrade or switch to another version, you only need to update in the parent class container, without any modification of the subproject, or if a subproject requires a different version number, You only need to declare a version number in dependencies. Subclasses use the version number of the subclass declaration, not the parent class version number.

2, dependencies

As opposed to dependencymanagement, all life's dependencies in the dependencies are introduced automatically and are inherited by all subprojects by default.

3, the difference

Dependencies even if the dependency is not written in a subproject, the subproject will still inherit the dependency from the parent project (all inherited)

Dependencymanagement is simply a declaration of dependency and does not implement introduction, so a subproject needs to display the declaration that needs to be relied upon. If you do not declare dependencies in a subproject, 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 both version and scope are read from the parent Pom, and if the version number is specified in the Child project, The jar version specified in the subproject is then used.

4. MAVEN Convention is superior to configuration

It presents this concept to provide a reasonable default behavior for the project without unnecessary configuration. The default directory is provided

Src--> source code and test Code root directory

Source directory for main application code

Java source Code

Resource file for resources project

Test the source directory of the Code

Java Test Code

Resource file for resources test

Target compiled class file, jar file, etc.

For the MAVEN convention is better than the understanding of configuration, on the one hand, for small projects basically meet our needs basically do not need to configure things, use Maven has been configured, Quick Start, learning cost reduction, on the other hand, not meet our needs can also customize the settings, reflect the flexibility. The configuration is significantly reduced, and the more complex the project becomes, the more obvious the advantage becomes.