持续集成之路——Maven（续）

接上篇）在新创建了项目之后，可以看到目录结构：

 

      从图中可以看出，Maven自动将项目源文件和测试用例分别放到了不同的目录下，但是却使用了相同的包名。这样生成可执行的产品时，就比较容易将产品代码 和测试代码隔离开；同时测试用例也可以直接引用同一包中被测试的类，既符合了JUnit的规范，也使程序更易读。

      正如上图中标示，新建项目的JRE默认为J2SE-1.4，这会导致1.5之后的一些新特性得不到支持。可以通过下面的方法修改：

      2、使用Maven管理依赖

      在以往的开发中，我一般都会把用到的依赖都放到一个文件夹下，需要什么就像里面添加什么，然后和源文件一同放入到SVN中。其他开发人员在检出项目时会把这些包一起检出。但是这样做有几个弊端：

    （1）最明显的一个问题，就是代码库会变得异常地大，有时候会上百兆，检出的时间会比较长

    （2）为了保持每个开发人员的开发环境的设置都是独立的，我们会要求开发人员不能提交Eclipse项目配置文件， 如.project、.settings等。这就需要每个开发人员必须自己配置自己Eclipse的构建路径（Build Path）。如果有新的依赖提交，而其他开发人员不知晓的情况，就可能编译会出错；

    （3）Java的库文件对版本的要求比较严格，而有些第三方包发布并没有说明其所依赖的版本，需要自己苦苦寻找；

    （4）虽然我们并不常会看第三方库的源代码，但是有时候也需要进去了解一下，帮助解决问题。这时就需要自己在Eclipse中指定源文件的位置。

    而Maven很好的解决了以上问题，只需要一个配置文件，就可以搞定所有了。比如要在上面的MavenDemo项目中引入JUnit：

   

         点击OK后，就会将依赖自动下载到本地，并添加到项目的构建路径中，

           查看pom.xml的内容，就会发现依赖在文件中的配置：

view plain copy to clipboard print ?

1. < dependencies >   
2.     < dependency >   
3.         < groupId > junit </ groupId >   
4.         < artifactId > junit </ artifactId >   
5.         < version > 4.4 </ version >   
6.         < type > jar </ type >   
7.         < scope > compile </ scope >   
8.     </ dependency >   
9. </ dependencies >   

      如果以后需要更改版本，只需要修改这里的版本号即可，当然可以从依赖的页面中删除和添加。

      在上面提到了Maven可以自动管理依赖的依赖，为了显示这个强大的功能，特意引入了一个spring-core的包，然后切换到pom的 Dependencies Graph页面，可以看到，虽然只引入了一个spring-core，但是Maven却自动发现了它依赖的另外两个包，省去我们的很多麻烦。

 

        3. 运行测试用例

        在/src/test/java编写一个测试用例，然后直接在项目名称上点击右键，从菜单中选择Run as-->maven test。在运行过程中，Maven会自动下载需要的包，并且给出一份详细的测试报告。

 

      这种方式可以运行项目中所有用例。当然可以依照原来的习惯，在项目目录中选择一个文件，按照JUnit的方式运行。