简述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,才学到这点知识，希望能给后来人一点点帮助!