Maven-依赖管理机制

  Dependency Mechanism
Java项目开发中肯定需要大量的jar文件，也就是说你要依赖很多已经开发好的jar包。尤其是你要依赖很多开源的东东。有没有感到很迷糊，经常不知道要用到哪些，干脆全部拿来。多么希望用多少来多少，还不用我自己指定。再加上版本的问题，头大。maven号称有奇招。我们来看看maven的依赖管理机制吧。

1. <dependencies>   
2.         <dependency>   
3.             <groupId>junit</groupId>   
4.             <artifactId>junit</artifactId>   
5.             <version>3.8.1</version>   
6.             <scope>test</scope>   
7.         </dependency>   
8.   
9.         <dependency>   
10.             <groupId>log4j</groupId>   
11.             <artifactId>log4j</artifactId>   
12.             <version>1.2.11</version>   
13.             <scope>compile</scope>   
14.         </dependency>   
15. </dependencies>  

<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>3.8.1</version>
			<scope>test</scope>
		</dependency>

		<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>1.2.11</version>
			<scope>compile</scope>
		</dependency>
</dependencies>

 

1. Transitive Dependencies 传递性依赖  

Transitive Dependencies 传递性依赖

这个不难理解，大部分的jar都会对别的有依赖。如此下去会不断膨胀。比如Hibernate就依赖很多开源的jar。有很多你都不知道是干什么用的，你只是想用hibernate的功能。依赖环的出现也说不定哦。麻烦。Maven说可以帮你自动管理传递依赖的jar。爽吧。怎么做到的呢？得有两下子才行：
1. Dependency mediation - 依赖调停
调停什么？谁会有冲突？是版本！同一个jar包，又会有不同的版本，因为总是在升级嘛。当你所依赖的jar有不同的版本的时候，该选择那一个呢？那位说了，就选最新的呗。好主意，毕竟大部门软件都向下兼容，但这也不一定哦。看看maven怎么做。maven选择最近的一个版本。什么意思？
比如你的A项目：
A -> B -> C -> D 2.0 and A -> E -> D 1.0，什么意思？A依赖B，。。。一直到依传递依赖到D2.0。同时A还依赖了E到一直到D1.0。这就出现了冲突，你当然也可以再A里面配置指定依赖D2.0。如果你没在A的pom里面配置指定用哪一个。maven会替你找一个近的。哪个近？当然是D1.0，那build A的时候就会选择D1.0。什么原因？这样就好吗？得好好想想？ 你有什么看法？
有什么好想的？别这么纠结，就指定呗。说的容易，你想想很多时候你是不知道D的存在的，它很可能是个很底层的库，你只熟悉和你最近的项目B和E。

2. Dependency management - 依赖管理
依赖管理就是建议你尽可能的指定依赖的类库的版本。毕竟靠maven调停有一定的风险。

3. Dependency scope  - 依赖有效范围
这个很重要，试想一下，如果不控制，传递依赖可以跑到千里之外。后面再想说怎么用Dependency scope来控制传递到什么时候为止。

4. Excluded dependencies - 排除的依赖
如果我干脆不想引入D，因为我知道我不会用到那一部分功能。那我就可以利用"exclusion" element去排除它。

4. Optional dependencies - 可选的依赖
如果C和E对D都是可选的依赖关系，也就是没有D，C和E都还能工作。那么在C和E里面可以指定D为可选的。那么A就不会引用到D。这也不需要用"exclusion"去排除了。

Dependency Scope
前面说了，既然依赖是传递的，那就得控制传递到什么时候是个头啊。怎么控制？如果是你，你怎么想？ 依赖的目的是引用，我用到了他给我的功能，才需要啊。那怎么知道我有没有用到它？什么时候才能知道？你先想到什么了？compile！必须地！
1. compile
编译不了，说什么都白搭。所以必须能使编译通过。所以这个也是默认的scope。编译的时候需要什么就给你添加什么jar。

2. provided
谁来提供？想想看？你的运行环境。最典型的就是web应用，很多jar在web 容器里面就提供了，那我们就没有必要在发布的时候包含它了。不过编译和测试的时候也还是得要，因为这时还没有容器为你提供。这种scope的jar不能被传递？为什么？不同的容器有不同的内容吧。

3. runtime
运行时需要，编译的时候不用。但是test的时候肯定得要，不run怎么test啊。我一时想不出什么例子。你给点？

4. test
仅仅为test的用的，你肯定一下子就能想到junit。别的不多说。

5. system
如果你有一些包你自己的系统里有，你不想让maven从repository里面下载，你可以用这个选项。

1. <project>   
2.   ...   
3.   <dependencies>   
4.     <dependency>   
5.       <groupId>javax.sql</groupId>   
6.       <artifactId>jdbc-stdext</artifactId>   
7.       <version>2.0</version>   
8.       <scope>system</scope>   
9.       <systemPath>${java.home}/lib/rt.jar</systemPath>   
10.     </dependency>   
11.   </dependencies>   
12.   ...   
13. </project>  

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>javax.sql</groupId>
      <artifactId>jdbc-stdext</artifactId>
      <version>2.0</version>
      <scope>system</scope>
      <systemPath>${java.home}/lib/rt.jar</systemPath>
    </dependency>
  </dependencies>
  ...
</project>

6. import
你知道java是不能多继承的，maven也是。如果这样，似乎不太强大，所以maven可以让你用import从别的project中导入依赖。