MAVEN's Dependency analysis management

one, the dependence principle analysis

Jar Dependency Analysis: Maven's dependency management, using the nearest priority, order priority principle,

Maven dependency can be likened to a dependency tree, and the project itself can be considered a root node, as shown below

1, the nearest priority: that is, groupid and Artifactid phase, the closer to the root of the node, MAVEN preferred to select

For example above: N11 and N22 if GroupID and Artifactid are the same, MAVEN first relies on the version of the N11 jar

2, Order Priority: that is, GroupID and Artifactid in the same time, who ranked in front, priority selection

For example: If N21 and n23 have the same groupid and Artifactid, then Maven would prefer N21 this jar version

The order of the XML dependency in Maven determines the order of dependencies, such as graphs, N11 and n12 as direct dependencies, n21,n22,n23 as indirect dependencies,

The order of indirect dependencies is determined by the order in which the upper dependencies appear, sorted sequentially, GroupID and artifactid the same precedence excluding two, and dependent on the management

1, the problem we encountered

1) No matching class, no matching method

2) A method differs from the expected effect

3) No related classes, no related methods

2, cause of the problem: dependency conflict

3, the nature of the problem:

1) behavior of non-spec developers: Developers are free to add dependencies, not strict specifications

2) Developer omission, a) not checked for existing versions dependent, B) failed to check for indirect dependencies and existing dependencies

4, how to solve the dependency problem. Initiate

From 3 We know that the nature of the dependency problem is a) reliance on management system B) developer negligence

In order to eliminate the chaos of dependence management, the following measures, to stimulate, brainstorming, we add

1) Extract the modules public dependency jar and put it into the parent unified management, for example:

Log frame: commons-logging,log4j,slf4j

Common tools: Commons-lang,commons-codec,commons-collections

Framework core dependencies: Spring,hibernate, etc.

2) limit add-on randomness

A) Carefully check whether the existing class library meets the requirements before adding dependencies. b) Assess the frequency of application applications that depend on the range.

c) How easy it is to customize the implementation of this dependent feature

3) Add a pre-reliance check: Open dependency hierarchy using the filter with the power of Eclipse

A) Check if the dependency already exists

b) Add the dependencies you need, then open dependency hierarchy using filter, check to see if the indirect dependencies of the add dependency already exist,

If exclusions exist. If it does not exist, declare it directly within the Pom file, clear that dependency, and then exclude indirect dependencies

c) Class Library upgrade check: When upgrading the class library version, the loop step A, a, b

d) Select a compatible class library: When multiple class libraries depend on the same class of libraries, run-time tests, whether they work properly, select a compatible class library

e) Exclude class libraries based on experience: for example Cps-ops as shown below

In the figure above hdiv-jstl-taglibs due to indirect dependence, introduced spring2.5,spring2.5 this is a complete class library, including BEANS,CORE,AOP and so on

Groupid,artifactid, respectively, are:

<groupId>org.springframework</groupId>

<artifactId>spring</artifactId>

On the surface there is no conflict with Artifactid for Spring-core,spring-bean,spring-aop,spring-web artifact, and Eclipse does not prompt conflict,

However, when deployed, Spring2.5.jar and Spring-core,spring-bean,spring-aop,spring-web have a running environment, resulting in confusion

Exclude conflicting jars based on experience