Maven心得

Maven 作为一个 Ant 的替代者，在 Java 的圈子里来势汹汹的，好像吾誓取而代之的样子，但是在国内总是不温不火，继续 ant 似的。我之前学习 Maven ，查了国内的资料，只有 JavaEye 上有位高人 Juven Xu ，把 Maven 的文档翻译成了中文（ Maven 权威指南 ) ，本人的 Maven 知识，基本就是中英文两个版本的 Maven Book 来学习的。

虽然在国内好像资料不是很多，即使在论坛里讨论，也是质疑的声音比较多，很多还是坚守 Ant 的阵地，有的人等待 Ant 的正统后代 Ivy ，总之，氛围不是很浓。但是论坛里一位兄弟的一句话倒是道出了真机 —— 中国人对这个没什么感觉，但是老外超喜欢！

我也是这样，所以才不得不用上了 Maven ，才所以有了一些小小的心得。

首先， Maven 是什么。

这个问题可大可小啊，往小里说， Maven 不过是又一个 Build 工具罢了，只不过比 Ant 更为强大一些罢了。往大里说，那 Maven 就是整个工程管理的全部了！几乎一个工程需要的东西，它无所不包了。

那么首先把它当做一个 Build 工具来说吧。说到这个，就不得不提它的一个基本理念，就是 约定优于配置 ，这个概念好像来自于 RoR 吧。什么意思呢？就是与其不停的写配置来定义一个项目，那么还不如指定一套约定，大家都来遵守。比如工程的目录结构， Maven 就有约定的，它认为一个工程目录下，应当有一个叫 src 的目录，其下有 main 和 test 目录，分别放应用要用的 source 和 test 用的 source ，然后呢，又分别在他们下面有 java 代码的目录和 resources 的目录，总之，就是结构是预先定义好的，如果你没有修改过配置，那么就是这样了。而据说 Ant 的话，每个项目都是自定义的。这样的好处很多，首先，一个有 Maven 的人，接触到一个新的项目的时候，只要是 Maven 的，他就可以很快上手了，而不用到处问项目结构。而对于 IDE 来说，应该也是一个好事，这样， Eclipse 的项目就可以更方便的转到另一个 IDE 比如 NetBeans 了，因为这个是一套规范。可能你不需要换 IDE ，但是如果是一个 team 而言，就更好了，因为可能你喜欢 NetBeans ，另一些喜欢 Eclipse ，那么大家完全可以用自己喜欢的 IDE 开发了。

说到了约定，除了文件结构外，还有对于整个开发流程的约定，对于 ant 和 Makefile 而言，也可以使用类似 “make install” 这类的命令来执行响应的操作，但是这些都是自己写的，比如对于 Makefile ，我们可以发现，有的可以执行 make clean ，有些却不可以，因为他们这些都是靠开发者自己配置出来的，虽然我们尽量符合标准，但是还是难免有差别。这对于其他人来说，非常痛苦，非得看一遍 Makefile 才行（大家也知道，复杂的 Makefile 还是挺烦的，又是 include 这个，又是 include 另一个，而且 Makefile 还有一些潜规则，很烦人），好吧，我承认比较熟悉 Makefile ， Ant 不懂的，所以无法和 Ant 比较，呵呵。

但是到了 Maven 就不同了， Maven 不愧为 Maven （专家，内行），它已经整理出一套规则，无论是 clean ， build 还是生成 site ，都是有一套约定，具体可以参看 构建生命周期 一章。这样的话，只要是 Maven 的项目，你都可以确定，要清理项目，只要用 clean 就可以，要编译，只要用 compile 就 ok 了，打包就是用 package 。不用每个新项目，都要重新学习一遍。

但是有个问题，每个项目都有些不同，比如打包吧，一个桌面应用，可能是 jar 包，而一个 web 应用，就要 war 包了，但是都是对应生命周期的 package 阶段，这个又怎么办呢？其实呢，生命周期具体做什么，并没有写死在生命周期的阶段中，而是用目标（ Goal ）来实现的。那么，目标呢，又是写在 plugin 里的。每个 plugin 可以提供一个或一个以上目标。比如如果是桌面应用，那么 package 这个阶段，就是绑定在 jar 这个 plugin 的 jar 目标上，而 web 应用则是绑定在 war 这个 plugin 的 war 目标上的。

由此可见， Maven 自身也不过是个框架罢了，他用自己最基本的功能，来管理这些插件，从而实现 Maven 的高灵活度。如果你愿意，可以自己写插件来完成新的功能，而事实上，很多人都这样干了，所以有很多现成的插件可以让你完成几乎所有的事——基本上所有和 Java 有关的东西，都可以找到，常见的 Struts 、 Spring 、 Hibernate 、 Log4J 什么的，当然不在话下啊，连 GWT 这样比较妖怪的（因为它是把 Java 编译成 JavaScript ，相当强大），都能用 Maven 来实现，甚至连 JRuby 这样的，都可以了。

那么插件哪里来呢？这里就要说到一个概念——仓库（ Repository ），仓库分为远程和本地两个。远程的仓库呢，负责提供这些插件，而本地嘛，一个主要目的是为了做镜像——总不能每次都去下载吧。当然另一个目的，要运行 java 应用，要设置 classpath 嘛，所以也要下载到本地（ classpath 能设置到 http 路径吗？不清楚）。

说到了仓库，那么就要说到 Maven 的另一个功能——依赖管理。因为依赖管理，离不开仓库。

其实很多人都遇到这个问题，就是解决依赖关系很麻烦。比如 Spring ，你要 Spring ，但是发现，原来 Spring 还要另一个包，加了另一个包啊，又发现它也需要其他包，呵呵，类似的情况，也发生在 Redhat Linux 中，大家应该有些耳闻吧。

而用了 Maven 呢，你只要说，我要一个 Spring ！然后，所有的依赖，都自动帮你解决了——听上去很像 Debian/Ubuntu 的 APT 吧！其实也就差不多啦。但是， Spring 怎么知道自己要哪些依赖呢，是写在 POM 文件里的，里面写了关于 Spring 这个包的信息。然后呢， Maven 会自动从仓库里把需要的依赖包都下载下来。(以后，我写一下这样做带来的问题吧）

所以说，仓库里，放的就是 plugin 和 java 的 package （可能有其他的东西，俺不知道）

最后，就要说一下这个 POM 文件了。其实刚才说了这么多，还有一个问题没有解决呢——我怎么定位一个文件呢，无论是 plugin 还是依赖包，我总得定位它吧， Maven 里是靠“坐标”的，一个坐标是靠 Group Id ， Artifact Id 和 Version 来定位的， Artifact Id 就是这个包的名字啦， Group 呢，一般是 java 的 package name ，当然也可以不是，只要保证唯一性就可以了。具体的，大家可以看看文档吧。

我要累死了，下次再说，下次再说…

____________________________________________________

原来之前一篇博文已经说到这个问题，参看

依赖库的版本一致性