[转]Maven Dependency Mechanism - 依赖管理机制

 

之前在一个公司接触了一个项目，框架师用到了maven，作为一个小公司的码农，新事物总是令人神往，恰值周末，在iteye看到一篇文章。个人惯例，原作者博客地址：http://jackycheng2007.iteye.com/

 

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

<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>

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里面下载，你可以用这个选项。 

<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中导入依赖。