Maven Combat (vi) The difference between---dependencies and dependencymanagement

in the previous project encountered a number of jar package conflicts, and then there are many people do not know the difference between dependencies and dependencymanagement, this article summarizes these differences.

1.depencymanagement Application Scenario

when we have a lot of project modules, we use Maven to manage our projects very conveniently and help us manage the methods of build, document, report, rely,scms, publish, distribute. It is easy to compile code, manage dependencies, manage binaries, and more.

since we have a lot of modules, we have abstracted a layer and pulled out a itoo-base-parent to manage the public dependencies of the subproject. 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.

in the POM file at the top of our project , we will see the dependencymanagement element. This element is used to manage The version of the jar package, so that the subproject references a list version number that is dependent instead of being displayed. Maven walks up the parent-child hierarchy until it finds a project with the dependencymanagement element, and then it uses the dependencymanagement The version number specified in the element.

Take a look at the applications in our project:

Pom inheritance diagram:

Dependency Relationship:

Itoo-base-parent (Pom.xml)

[Java]View PlainCopy print?

2. <dependencyManagement>
6. <dependencies>
8. <dependency>
10. <groupId>org.eclipse.persistence</groupId>
12. <artifactId>org.eclipse.persistence.jpa</artifactId>
14. <version>${org.eclipse.persistence.jpa.version}</version>
16. <scope>provided</scope>
18. </dependency>
22. <dependency>
24. <groupId>javax</groupId>
26. <artifactId>javaee-api</artifactId>
28. <version>${javaee-api.version}</version>
30. </dependency>
32. </dependencies>
34. </dependencyManagement>

Itoo-base (Pom.xml)

[Java]View PlainCopyprint?

2. <!--inherit from parent class--
4. <parent>
6. <artifactId>itoo-base-parent</artifactId>
8. <groupId>com.tgb</groupId>
12. <version>0.0. 1-snapshot</version>
14. <relativepath>, .... /itoo-base-parent/pom.xml</relativepath>
16. </parent>
18. <modelVersion>4.0. 0</modelversion>
20. <artifactId>itoo-base</artifactId>
22. <packaging>ejb</packaging>
26. <!--dependencies--
28. <dependencies>
30. <dependency>
32. <groupId>javax</groupId>
34. <artifactId>javaee-api</artifactId>
36. </dependency>
40. <dependency>
42. <groupId>com.fasterxml.jackson.core</groupId>
44. <artifactId>jackson-annotations</artifactId>
46. </dependency>
50. <dependency>
52. <groupId>org.eclipse.persistence</groupId>
54. <artifactId>org.eclipse.persistence.jpa</artifactId>
56. <scope>provided</scope>
58. </dependency>
60. </dependencies>
62. </project>

the benefit of doing this is to manage the version number of the project uniformly, to ensure that the dependencies and versions of the applications are consistent, to ensure that the same results are tested and published, and therefore to define common dependencies in the top-level pom . You can also avoid declaring a version number in each subproject you use, so that when you want to upgrade or switch to another version, you only need to update it in the parent class container, without any modification of the subproject, or if a subproject requires a different version number, only the dependencies You can declare a version number in the Subclasses use the version number declared by the subclass and do not inherit the version number of the parent class.

2,Dependencies

All life dependencies in dependencies are automatically introduced relative to Dependencymanagement and are inherited by all sub-projects by default.

3. Difference

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

dependencymanagement only the declaration relies on, and does not implement the introduction , so the subproject needs to display the claims that need to be relied upon. If a dependency is not declared in a subproject, it is not inherited from the parent project, and the item is inherited from the parent project only if the dependency is written in the subproject and no specific version is specified , and both version and scope are read from the parent Pom; In addition, if a version number is specified in a subproject, the jar version specified in the subproject is used .

4.Maven convention is better than configuration

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

SRC -- root directory for > source Code and test code

Source directory for main application code

Java Source Code

resource files for the resources project

source directory for test code

Java Test Code

resource file for the resources test

Target compiled class files,jar files, etc.

for the understanding that MAVEN convention is better than configuration, on the one hand, for small projects basically meet our needs do not need to configure their own things, using Maven has been configured to quickly get started, learning cost reduction, on the other hand, You can also customize settings that don't meet our needs and show flexibility. The configuration is greatly reduced, and as the project becomes more complex, this advantage becomes more pronounced.

http://blog.csdn.net/liutengteng130/article/details/46991829

Maven Combat (vi) The difference between---dependencies and dependencymanagement