前言
相信仅仅要做过 Java 开发的童鞋们，对 Ant 想必都不陌生，我们往往使用 Ant 来构建项目，尤其是涉及到特别繁杂的工作量。一个 build.xml 可以完毕编译、測试、打包、部署等非常多任务，这在非常大的程度上解放了程序猿们的双手。但同一时候也存在一些其它的问题。比方：jar 文件管理混乱，每次都须要自己去下载；build.xml 因项目结构的不同导致差异性较大。
概况
自从项目中引入 Maven 以后，曾经 Ant 能解决的，Maven 提供了更加简洁的解决方式，而曾经 Ant 解决不了的。Maven 也能非常好的解决。这就直接导致了项目管理工具的更新换代。当然，这已不是什么新奇事了。仅仅只是，一直到如今才有时间来分享项目中使用 Maven 的感受。这一点上，真的非常抱歉，兴许会及时的更新。
Maven 的新手教程网上已经有非常多了。这里就不再赘述这些基本知识了。还没有接触过 Maven 的童鞋，请移步 Google 或 Baidu。
之后再回来看这篇文章。在这篇文章里，我主要结合项目中 Maven 的使用，以及须要注意的事项来与大家讨论。
原理
说到 Maven 的原理，事实上非常easy。就是採用远程仓库和本地仓库以及一个类似 build.xml 的 pom.xml，将 pom.xml 中定义的 jar 文件从远程仓库下载到本地仓库，各个应用使用同一个本地仓库的 jar，同一个版本号的 jar 仅仅需下载一次。并且避免每一个应用都去拷贝 jar。
同一时候它採用了如今流行的插件体系架构，仅仅保留最小的核心。其余功能都通过插件的形式提供。所以 Maven 下载非常小（1.1M），在运行 Maven 任务时。才会自己主动下载须要的插件。
并且，Maven 还是跨平台的，并且提供了支持非常多 Java IDE 的扩展插件。在开发中，我们大部分的时间，用到的是 Maven 的插件。对于公司内部来说，还是须要建立自己的私服的，只是，这里私服不是重点，就不再讨论了。
结构
项目中我们都会依据自己的习惯创建文件夹结构，尽管有规范。但难免会有疏漏。长此下去，项目的结构会越来越乱的。
Maven 攻克了这个问题，对于不同的项目。它提供了多种选择。并将其作为文件夹模板，例如以下图所看到的。
使用文件夹模板，能够使pom.xml更简洁。由于Maven2已经依据缺省文件夹，提前定义了相关的动作，而无需人工的干预。以resources文件夹为例：
- src/main/resources，负责管理项目主体的资源。在使用Maven2运行compile之后，这个文件夹中的全部文件及子文件夹。会拷贝到target/classes文件夹中，为以后的打包提供了方便。
- src/test/resources。负责管理项目測试的资源。在使用Maven2运行test-compile之后，这个文件夹中的全部文件及子文件夹，会拷贝到target/test-classes文件夹中，为兴许的測试做好了准备。
这些动作在 Maven1 中。是须要在 maven.xml 中使用<preGoal>或<postGoal>来完毕的。现在。全然不须要在pom.xml中指定就行自己主动完毕。
在src和test都使用resources，方便构建和測试，这样的方式本就已是前人的经验。
通过使用Maven2。使这个经验在开发团队中得到普及。
生命周期
在 Maven2 中有了明白的生命周期概念，并且都提供与之相应的命令，使得项目构建更加清晰明了。基本的生命周期阶段：
- validate，验证project是否正确，全部须要的资源是否可用。
- verify。执行不论什么检查，验证包是否有效且达到质量标准。
- integration-test，在集成測试能够执行的环境中处理和公布包。
- generate-sources，产生应用须要的不论什么额外的源码，如xdoclet。
- compile。编译项目的源码。
- test-compile，编译项目測试代码。
- test，使用已编译的測试代码。測试已编译的源码。
- package，已公布的格式。如jar，将已编译的源码打包。
- install。把包安装在本地的repository中，能够被其它project作为依赖来使用。
- deploy，在整合或者公布环境下执行，将终于版本号的包复制到远程的repository，使得其它的开发人员或者project能够共享。
假设要运行项目编译。那么直接输入：mvn compile就可以，对于其它的阶段能够类推。
阶段之间是存在依赖关系（dependency）的，如test依赖test-compile。在运行mvn test时，会先运行mvn test-compile，然后才是mvn test。当然，开发中，我们一般都不会直接操作 Maven 的。而是在 Eclipse 中使用 Maven 插件，当中用的最多的命令就是 clean 、compile 、install 、deploy 等。
依赖
说完生命周期，另一个必需要说的就是依赖管理了。Maven 中是通过在 pom.xml 中加入依赖从而来引入 jar 包的。其原理是：每个 jar 都会有独立的坐标，Maven 就是通过坐标来定位到详细的 jar 的。
就好像平面坐标系一样，通过 x 轴 和 y 轴定位一个坐标点。Maven 定义了这样一组规则：世界上不论什么一个构件都可以使用 Maven 坐标唯一标识，Maven 坐标的元素包含 groupId 、artifactId 、version 、packaging 、classifier 。仅仅要我们提供正确的坐标元素，Maven 就行找到它。
建议
有的人可能会有疑问，曾经没有 Maven 的时候。我们能够去各自的官网下载 jar，但如今仅仅能通过 pom 引用 jar。那么怎样知道须要加入哪些依赖呢？还有须要什么版本号呢？这也是为什么有一部分习惯了自己下载 jar，而到了 Maven 这不知道该怎么用了。
当然，Maven 还不是智能的，你不可能直接命令 Maven 直接给你找项目所须要的各种组件，也许以后这种智能化的软件管理工具会出现，至少如今还没有。
因此，还得须要你自己去加入 pom 依赖。至于该怎样找。这里我告诉大家一个方法。尽管方法有点笨，但也许对你高速定位到详细组件有所帮助。
举个样例，假如如今须要加入 Hibernate 的依赖，但详细哪个版本号呢。能够先不用管，直接去 Baidu 或者 Google，以“ maven spring repository ”为keyword搜索，往往第一个链接中，就是你须要的方案。
进入第一链接之后。你会看到这样一个页面，搜索的结果都是关于 Spring 的，依据你的须要。选择一个链接进入。列表中有各个版本号的组件，点击你须要的版本号，然后就会看到 Maven 坐标。把它拷贝到你的 pom 文件里就噢啦。
当然，这仅仅是一种方法，仅仅针对刚接触 Maven 的童鞋们。随着项目经验的增多，以后你就会越来越发现。Maven 解放的不仅仅是你的双手，还有你最宝贵的时间。
感受
在一个项目中选择使用一款管理工具是有风险的。那么该怎样把这样的风险减到最低。或者让它转变为对项目开发有利的一方面呢？这就须要架构师或者项目组长，在项目開始之前进行严格的技术考察、技术（工具）选型、学习成本的分析等。
选择一种技术或者一款工具，不能只由于它的流行程度，还要考虑到本公司开发者的技术程度。技术（工具）的跨平台性考虑，扩展性与集成性的考虑，以及技术（工具）稳定性的考虑等。当然，对于一种新技术（对开发者来说是新技术），还须要考虑学习成本。这些都制约日后的开发效率、开发进度，以及出问题后能不能解决等。
所谓的技术选型，并非选出多么新的技术。也并非选出成本最低的技术，而是可以利用本公司的优势，找出最适合本公司的技术和工具，在有限的范围内、有限的时间内把本公司的能力发挥到最大。
就比方，假设在项目管理工具上，公司里一直都在用 Ant，并且用的也特别的熟练，况且项目的时间特别紧急。公司的开发者对 Maven 都没有接触过。那么就不用再考虑 Maven 了。由于时间在那摆着呢。并且还有开发者的学习成本。这样的情况下再选择 Maven，这不是 zuo si 吗？当然，这样的样例不胜枚举。这里就不再多说了。
结束语
本来应该在最后说的话，都放在了感受里边。对于项目管理。还有非常多欠缺的，希望在日后的工作中继续积累经验吧。当然，也希望大家可以多交流，共同进步。
版权声明：本文博客原创文章，博客，未经同意，不得转载。