Turn: dependencyManagement and dependencies differences and differences dependencies dependencyManagement

dependencyManagement and dependencies difference

　　Recently while reading maven project code, the difference between the dependencyManagement and dependencies not know much about, are summarized by project examples: There are projects under epps-demob-pom is a module epps-demob-war.

A, dependencyManagement scenario

　　For proper operation of the project, we must make use of all of the sub-modules unified version of dependency, dependency and the need to ensure consistent application of the various versions of the project, to ensure the release of the test and the result is the same. In our project pom top of the file, we will see dependencyManagement elements. Through its elements to manage jar package version, let subproject cited a reliance version number listed without display. Maven will walk up the parent-child hierarchy until it finds a project has dependencyManagement elements, then it will use the version number specified in this dependencyManagement element.

　　epps-demob-pom in dependencyManagement follows:

    <modules>
        <module>epps-demob-war</module>
    </modules>
    <properties>
            <spring-version>3.1.1.RELEASE</spring-version>
    </properties>
    <dependencyManagement>
          <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-web</artifactId>
                <version>${spring-version}</version>
          </dependency>
    </dependencyManagement>

　　epps-demob-war in the following dependency:

    <dependencies>
            <dependency>
                  <groupId>org.springframework</groupId>
                  <artifactId>spring-web</artifactId>
            </dependency>
    </dependencies>

　　The advantage of this: the unified management of the project version numbers, dependencies and ensure consistent application of the various versions of the project, to ensure the release of the test and the results are the same, therefore, the definition of a common dependence on the top floor of the pom. And will avoid all declared in each subproject use of a version number, so when you want to upgrade or switch to another version, only need to update the parent container, a sub-project does not require any modification; if a subproject when need another version, just declare a version number at the dependencies in. Subclass will use the version number of the subclass declaration, not inherited from the parent class version number.

Two, dependencies scenarios

　　With respect to the dependencyManagement, if dependencies introduced by the jar epps-demob-pom, the default is inherited by all sub-modules.

Three, dependencyManagement and dependencies difference

　　dependencyManagement was only declared dependency, it does not implement the introduction, and therefore need to rely on sub explicitly declare the need. If you do not declare a dependency subproject, is not inherited from the parent project down; only write the dependencies in subprojects, and does not specify a specific version, will be inherited from the parent project, and version and scope They are read from a parent pom; Also, if the version number is specified in sub-project, it will use the specified jar in subprojects version.
　　dependencies even if not written in the sub-module dependencies, then the sub-module dependencies will still inherit from the parent project (all inherited).

　　Recently while reading maven project code, the difference between the dependencyManagement and dependencies not know much about, are summarized by project examples: There are projects under epps-demob-pom is a module epps-demob-war.

A, dependencyManagement scenario

　　For proper operation of the project, we must make use of all of the sub-modules unified version of dependency, dependency and the need to ensure consistent application of the various versions of the project, to ensure the release of the test and the result is the same. In our project pom top of the file, we will see dependencyManagement elements. Through its elements to manage jar package version, let subproject cited a reliance version number listed without display. Maven will walk up the parent-child hierarchy until it finds a project has dependencyManagement elements, then it will use the version number specified in this dependencyManagement element.

　　epps-demob-pom in dependencyManagement follows:

    <modules>
        <module>epps-demob-war</module>
    </modules>
    <properties>
            <spring-version>3.1.1.RELEASE</spring-version>
    </properties>
    <dependencyManagement>
          <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-web</artifactId>
                <version>${spring-version}</version>
          </dependency>
    </dependencyManagement>

　　epps-demob-war in the following dependency:

    <dependencies>
            <dependency>
                  <groupId>org.springframework</groupId>
                  <artifactId>spring-web</artifactId>
            </dependency>
    </dependencies>

　　The advantage of this: the unified management of the project version numbers, dependencies and ensure consistent application of the various versions of the project, to ensure the release of the test and the results are the same, therefore, the definition of a common dependence on the top floor of the pom. And will avoid all declared in each subproject use of a version number, so when you want to upgrade or switch to another version, only need to update the parent container, a sub-project does not require any modification; if a subproject when need another version, just declare a version number at the dependencies in. Subclass will use the version number of the subclass declaration, not inherited from the parent class version number.

Two, dependencies scenarios

　　With respect to the dependencyManagement, if dependencies introduced by the jar epps-demob-pom, the default is inherited by all sub-modules.

Three, dependencyManagement and dependencies difference

　　dependencyManagement was only declared dependency, it does not implement the introduction, and therefore need to rely on sub explicitly declare the need. If you do not declare a dependency subproject, is not inherited from the parent project down; only write the dependencies in subprojects, and does not specify a specific version, will be inherited from the parent project, and version and scope They are read from a parent pom; Also, if the version number is specified in sub-project, it will use the specified jar in subprojects version.
　　dependencies even if not written in the sub-module dependencies, then the sub-module dependencies will still inherit from the parent project (all inherited).