简述maven,make,ant,jenkins,jenkins plugin, maven plugin之间的关系
现在研究CI(持续集成)链,公司要使用jenkins,刚开始接触很多不懂,现在经过一个多月的查找资料,终于明白了一些
现在网上的资料特别的混乱,有的特别的基础,学了还是什么都没搞明白;有的是很深,一点基础都不讲,怎么也看不明白,中间层很欠缺。也许使用这些技术的公司,对于员工都进行了很好的培训,基础的东西一听都明白了,但是对于自学使用这些工具的人来说,如果不能提纲挈领,抓住要领,学起来真费劲。下面,我就给根据我的理解,来说一说,希望对看到这篇文章的人有帮助,错误之处,敬请指正。
1. Make工具
这个工具是最最原始的工具了,在linux下编过程序,看过比较大的c/c++代码的人应该都听说过这个工具(Windows下对应的工具为nmake)。它负责组织构建的过程,也就是负责指挥编译器如何编译,连接器如何连接,最后生成一个可用的文件。
2. Ant工具
但是有人觉得make工具的很难使用,他的语法很难理解,就发明了ant
3. Maven工具
Maven工具是对ant工具的进一步改进(这么说不太准确,但是可以这么理解)。
在make工具中,如果我们要编译某些源文件,我们肯定首先要安装编译器等工具。但是有时候需要不同版本的编译器,在java的编译器需要不同的各种包的支持,如果把每个包都下载下来,在makefile中进行配置制定,当需要的包非常多时,很难管理。
- 例如一个web项目,可能使用到很多技术,面向对象、泛型、or-mapping、依赖注入(spring-framework)、全文检索(lucene)、数据库、集群、工作流、web service等等。
- 由于使用了多种技术,这些技术可能是JDK提供的,也可能是第三方开源组织提供的,或者不同的商业公司提供的。
- 于是出现了一个新的难题,就是包依赖复杂性。以前,你很难想象你的代码依赖数十个不同开源组织、商业公司提供的库。例如,我们经常使用的log4j、junit、easymock、ibatis、springframework,每个组件都有悠久的历史,存在不同的版本,他们之间版本还有依赖关系。
- 项目依赖的复杂性,经常的,一个较大部门有10-30个项目是常事,项目之间有不同版本的依赖关系,部门与部门之间的项目也存在复杂的版本依赖关系。
- Eclipse本身提供Project的依赖,但是简单的依赖显然解决不了问题。例如Project B依赖Project A,Project A依赖第三方的jar包abc-1.0.jar,那么需要在两个项目的lib下都存放abc-1.0.jar,这产生冗余,当Project数量多起来,这个冗余就产生了管理问题,如果需要将abc-1.0.jar升级为abc-1.1.jar,则需要在两个Project中同时修改,如果Project数量达到10个以上,而且是不同项目组维护的项目,这个就是非常麻烦的事情。而且Project A修改依赖,为啥需要Project B也作相应的修改呢?
- 需要解决此问题,就需要在Project A的包中描述其依赖库的信息,例如在META-INFO记录所以来的abc-1.0.jar等。Eclipse的plug-in拥有类似的方案,但是这样一来,就使得开发Project B的项目组,需要把Project A的代码从源代码库中check out出来。在依赖链末端的项目组是很惨的。
- 由于Project数量众多,关系复杂,dailybuild的ant脚本编写成了很麻烦的事情,使用Project依赖的方式,更加使得编写dailybuild ant script是非常痛苦的事情。
- 参考:http://www.cnblogs.com/jobs/archive/2007/09/24/903731.html
这样,于是人们发明了Maven工具。Maven使用配置文件pom.xml对环境进行配置,例如设定编译器的版本,设定所需支持包的URL,这样maven就可以自动去下载所需的包。这样如果需要对构建环境进行改变时,直接改变pom文件就可以了,maven会自动网络上下载配置的包。
Maven像make一样,是个构建(build)工具,它如何调用各种不同的编译器连接器等呢? 这就是Maven plugin (maven 插件)。maven插件是为了使maven能够实用各种工具。不同的工具有对应的插件。
Maven比make的更加大的地方是,可以利用一些别的工具,实现对编译结果的统计,对源代码的检查,对于代码的测试等。例如checkstyle,cobertura等,都有对应的Maven插件。
4. Jenkins工具
Maven已经很强大了,那Jenkins是个什么东西?
其实Maven还是不够强大。Maven可以控制编译,控制连接,可以生成各种报告,可以进行代码测试。
可是如何控制这个流程呢? 编译还是先连接?先进行代码测试,还是先生成报告??
可以使用脚本来对maven进行控制,实现这些流程的控制。但是,很不方便。即使能够走完整个流程,但是查看结果(例如代码静态分析的结果)时,也不方便。设想我们查看了代码覆盖率的结果,又想查看代码style的结果,又要对这些结果进行评价,还要发送给开发人员........太罗嗦了,有没有自动化图形界面实现这些过程的工具????
有,这个工具就是Jenkins。
Jenkins能够对流程进行控制,对能够对各个阶段生成的各种结果进行综合,以图表的形式呈现出来。
但是,不同的工具生成不同格式的结果,Jenkins如何让这些结果呈现出来??
这就是jenkins插件,Jenkins插件使maven中用到的各种工具生成的结果能够在Jenkins中呈现出来。
5. 一些特殊的东东
有些工具,不能被maven使用,却可以通过Jenkins调用脚本来生成结果,并有对应的Jenkins插件,将结果Jenkins中显示出来,例如cppcheck,CCCC等工具
6. Jenkins项目中对于项目配置中工具的配置与workspace中pom文件的该工具的配置的关系
例如,使用该cobertura工具,需要在jenkins中安装对应的插件,在项目设置中,制定cobertura-result所在的目录
但是使用cobertura工具的哪个版本?obertura如何找到需要检查的源文件?cobertura工具会把检查的结果放到哪个目录?
这些设置需要使用pom文件来配置的。
7. pom.xml与makefile
maven中使用的pom与make中使用的makefile作用差不多
但是在maven中,如果想编译某个文件夹下所有文件(包含子文件夹的文件)该怎么办呢?
我现在的方法是使用aggregation 和 inheritance ,详见pom reference(http://maven.apache.org/guides/introduction/introduction-to-the-pom.html )
Inheritance:
If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.
Aggregation:
And if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.
8. 总结:怎么样,看了这篇文章是不是思路逐渐的清晰起来了!!!
我讲的可能不是很严谨,但大体是这么个意思。
再说,明白这些也没有多大的意义,我们的终极目的是使用这些工具,来对代码进行分析,提高代码的质量。
如果您通过读这篇文章,明白了这些工具大体的框架,那么剩下的就是仔细研究各个分析工具的具体使用,希望能够通过使用分析工具提高大家的代码质量。
忙了一个月,看了好多的英文html,才学到这点知识,希望能给后来人一点点帮助!