Build a MAVEN project under Mac OS X + idea--Maven's dependency management

The previous blog post about how to install Maven is a sequel to how Maven manages dependencies.

The strong thing about Maven is management dependency. Relying on delivery, dependency inheritance, and pom imports make it easy to rely on version management. By relying on scope implementations to join dependencies during different lifecycle periods.

The following is one of the simplest examples of adding dependencies to the current project:
IntelliJ idea > Preferences > Builds, Execution, deployment > Build Tools > Maven
Importing the "Import Maven projects automatically" check box. If this column is not checked, idea will have a floating hint in the upper-right corner, or you can click on it from the prompt.
Next, add a dependency to the Pom.xml and the IDE will automatically add this dependency to external libraries.

     <dependency>
            <groupId>commons-lang</groupId>
            <artifactid>commons-lang</ artifactid>
            <version>2.6</version>
        </dependency>

# # depend on the passing #
For example, I added JUnit to the pom.xml, and JUnit relies on Hamcrest-core. But I don't have to add the dependency on Hamcrest-core, MAVEN will automatically do it, so my external libraries not only have junit, but also hamcrest-core.

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>

It relies on scope compile: The default scope, if no scope is written in the dependency node, it defaults to compile provided:jdk/the container will generate/provide this dependency at runtime Runtime: Dependencies are only required at run time, not required at compile time test: dependencies are for testing only, not for real appliation, such as adding junit dependencies, you can add scope = Test, The premise is that application itself really does not need to use the JUnit system: It looks like it has been deprecated ... import: Import the dependencymanagement part of another POM

# # rely on inheritance #
Dependency inheritance has two important roles: to add the public dependencies of a subproject to the parent project, and the pom.xml of the child Project manages the dependent version by the version number stated in the dependencymanagement of the parent project

The following example comes from the MAVEN official documentation. Project A is a parent project. Project B is a subproject of a, so B inherits the dependency of a declaration in the dependencymanagement paragraph, namely: a-1.2,b-1.0,c-1.0,d-1.2.

But since B itself has a definition of dependence on a and C, for dependency A, B will use its own defined a-1.0. There is no version defined in the dependency c,b, so maven will go back to father a to find the version definition for C, so it is c-1.0. For dependency B, it is not defined in B's own Pom, so inherits from Father A,b-1.0. For the dependence D, father A has, own dependencymanagement also has, the priority chooses own, therefore is c-1.0.

  <parent>
    <artifactId>A</artifactId>
    <groupId>maven</groupId>
    < Version>1.0</version>
  </parent>

Pom.xml of Project A:

<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>maven</groupId>
 <artifactId>A</artifactId>
 <packaging>pom</packaging>
 <name>A</name>
 <version>1.0</version>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>test</groupId>
       <artifactId>a</artifactId>
       <version>1.2</version>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>b</artifactId>
       <version>1.0</version>
       <scope>compile</scope>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>c</artifactId>
       <version>1.0</version>
       <scope>compile</scope>
     </dependency>
     <dependency>
       <groupId>test</groupId>
       <artifactId>d</artifactId>
       <version>1.2</version>
     </dependency>
   </dependencies>
 </dependencyManagement>
</project>

Project B's Pom.xml:

<project>
  <parent>
    <artifactId>A</artifactId>
    <groupId>maven</groupId>
    <version>1.0</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>B</artifactId>
  <packaging>pom</packaging>
  <name>B</name>
  <version>1.0</version>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>test</groupId>
        <artifactId>d</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>1.0</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>c</artifactId>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

In general, Dependencymanagement is placed in the Pom.xml document of the top-level project to rely on the version control of the package to ensure that the dependencies used in each subproject are the same version. Dependencymanagement only affirms dependencies and versions and does not actually download dependency packs.

When the dependencies in the subproject has a dependency and no version number, Maven traces it back until it finds the dependent version in the upper Pom. Subprojects do not need to be shown to write dependent versions to achieve the purpose of a unified management dependent version.

If you want to pass the dependency on (to the subproject, or to the project that import the Pom), the dependency is defined in the Dependencymanagement section. If you do not want to use the dependent version defined in the pom that your Father/import in, then declare the dependency of the specific version number in the dependency section. Otherwise, you should only assert dependencies in the dependency section, not to declare dependent versions, and unify the dependent versions defined in the Pom that Father/import in, to implement versioning.

# # Dependency Import #
In larger projects, dependencies are more used for imports. This uses dependency import to implement the purpose of the B inheritance A, which was just implemented in the Dependent Inheritance section.
In the dependencymanagement section of Pom.xml B, the pom of import a:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>maven</groupId>
  <artifactId>B</artifactId>
  <packaging>pom</packaging>
  <name>B</name>
  <version>1.0</version>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>maven</groupId>
        <artifactId>A</artifactId>
        <version>1.0</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>test</groupId>
        <artifactId>d</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>test</groupId>
      <artifactId>a</artifactId>
      <version>1.0</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>c</artifactId>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

In large projects, it is very common for some modules to rely on certain projects, and in order to make these modules dependent on the project version, it is a good practice to use dependency inheritance + dependency import. Specify the dependent version in the root pom, import the root pom in the module, and unify the version defined by the root pom. In the future, when dependent versions are updated, you can only change the version number in the root pom. This is quite a design pattern ...

First of all, in the Dependencymanagement section of the root Pom–bom (Bill of material), the statement relies on Project1 and Project2, and the version refers to the variables defined in the Properties section. And in the root pom the child project parent is indicated.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.test</groupId>
  <artifactId>bom</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>
  <properties>
    <project1Version>1.0.0</project1Version>
    <project2Version>1.0.0</project2Version>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.test</groupId>
        <artifactId>project1</artifactId>
        <version>${project1Version}</version>
      </dependency>
      <dependency>
        <groupId>com.test</groupId>
        <artifactId>project2</artifactId>
        <version>${project1Version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <modules>
    <module>parent</module>
  </modules>
</project>

Next in the Pom-dependencymanagement section of the parent project, some external dependencies are defined and the version is specified. Sub-project Project1 and PROJECT2 are also defined.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.test</groupId>
    <version>1.0.0</version>
    <artifactId>bom</artifactId>
  </parent>

  <groupId>com.test</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.12</version>
      </dependency>
      <dependency>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
        <version>1.1.1</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <modules>
    <module>project1</module>
    <module>project2</module>
  </modules>
</project>  

Next came the pom of Project1 and Project2, whose Pom only affirmed the dependency but not the version, because the dependent version defined in the father's parent Pom was unified.

<project xmlns= "http://maven.apache.org/POM/4.0.0" xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemalocation= "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" >
  < modelversion>4.0.0</modelversion>
  <parent>
    <groupId>com.test</groupId>
    <version>1.0.0</version>
    <artifactId>parent</artifactId>
  </parent>
  <groupId>com.test</groupId>
  <artifactId>project1</artifactId>
  <version>$ {project1version}</version>
  <packaging>jar</packaging>

  <dependencies>
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
    </dependency>
  </dependencies>
</project>

<project xmlns= "http://maven.apache.org/POM/4.0.0" xmlns:xsi= /xmlschema-instance "xsi:schemalocation=" http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/ Maven-4.0.0.xsd "> <modelVersion>4.0.0</modelVersion> <parent> <groupid>com.test</gr oupid> <version>1.0.0</version> <artifactId>parent</artifactId> </parent> ;groupid>com.test</groupid> <artifactId>project2</artifactId> <version>${ Project2version}</version> <packaging>jar</