Maven Best Practices: Managing Dependencies __ Project Management

Some people think that Maven is a dependency management tool, of course the idea is wrong (specifically, MAVEN is a project management tool that runs through the lifecycle of the project, compiling, testing, packaging, publishing ...). , but Maven's impression of this error is also a reason, because Maven's dependency management is very strong, with Maven, you no longer need to face a large stack of jars, the problem of relying on conflicts and useless dependencies can be effectively prevented and resolved. This section describes how to use a good maven dependency management.

The simplest of dependencies

Dependencies are positioned using MAVEN coordinates, and the MAVEN coordinates are primarily composed of Gav (GroupId, Artifactid, version). So, using any one dependency, you need to know its MAVEN coordinates, and the search Maven warehouse can help you with how to find the MAVEN coordinates.

The simplest dependencies are: XML code <dependency> <groupId>junit</groupId> <artifactid>junit</artifactid>     ; <version>4.4</version> </dependency>

In the example above we declared a dependency on JUnit, its groupid is JUnit, Artifactid is JUnit, and version is 4.4. This set of Gav constitutes a maven coordinate, based on which Maven can find the corresponding Junit-4.4.jar file in the local or remote repository.

Dependency Collation

As the project grows, you become more dependent, for example, you rely on a bunch of spring jars, Org.spring.framework:spring-core, Org.spring.framework:beans, Org.spring.framework:spring-web, Org.spring.framework:spring-mock. Their groupid are the same, Artifactid different. To manage their version, you have a unified upgrade of them, changing version to the latest version one after the other. But obviously, when the POM is big, you might make a mistake, and when the version is inconsistent, some weird compatibility problems may arise.

For this, MAVEN has its solution: XML code    <dependencies>     <dependency>       <groupId>org.spring.framework</groupId>        <artifactId>spring-core</artifactId>       <version>${ spring.version}</version>     </dependency>     < dependency>       <groupId>org.spring.framework</groupId>        <artifactId>spring-beans</artifactId>        <version>${spring.version}</version>     </dependency>     <dependency>       <groupid>org.spring.framework</ groupid>       <artifactId>spring-web</artifactId>       <version>${spring.version}</version>     </dependency>      <dependency>       <groupid>org.spring.framework</groupid >       <artifactId>spring-mock</artifactId>        <version>${spring.version}</version>     </dependency>    </dependencies>      <properties>     < spring.version>2.5</spring.version>   </properties>  

Here we define a Maven property whose name is Spring.version and the value is 2.5. In this pom, we can refer to this property in the way of ${spring.version}. We see that all spring-dependent version elements are now ${spring.version}, and when Maven runs, it automatically replaces the reference with the value 2.5来.

When we need to upgrade spring, just change one place and you can now make sure that all spring dependencies are the same version.

Dependency Range (scope)

The first example of this article is actually flawed, and for junit, you typically only need it when you run your tests, that is, it doesn't make sense for Src/main/java's classpath, and it's not good to get junit jar files into the final release package. This unnecessarily increases the size of the release package.

Actually we should do this: XML code <dependency> <groupId>junit</groupId> <artifactid>junit</artifactid&     Gt <version>4.4</version> <scope>test</test> </dependency>

As a result, junit for the main source classpath is not available, for the test source classpath can be used, will not be packaged.

For example, when developing Java EE applications, we will definitely use SERVLET-API, which is necessary for both the main source and the test source code, because the SERVLET-API package is introduced into our codes. However, it is problematic to put it into the war package at the time of packaging, because the Web container provides SERVLET-API, and if we package it again it can cause a dependency conflict, as follows: XML code    <dependency>