64位CentOS:持续集成之路(2)

(接上篇)在新创建了项目之后,可以看到目录结构:

64位CentOS:持续集成之路

 

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

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

64位CentOS:持续集成之路

2、使用Maven管理依赖 

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

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

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

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

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

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

64位CentOS:持续集成之路

   

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

64位CentOS:持续集成之路

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

<dependencies>       <dependency>           <groupId>junit</groupId>           <artifactId>junit</artifactId>           <version>4.4</version>           <type>jar</type>           <scope>compile</scope>       </dependency>   </dependencies>  

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

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

64位CentOS:持续集成之路

3. 运行测试用例

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

64位CentOS:持续集成之路

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

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/23691.html