对Maven、gradle、svn、spring 3.0 fragment、git的想法

1.Maven

Maven可以构建项目，采用pom方式配置主项目和其他需要引用的项目。同时可结合spring3.0的新特性web fragment。

从现实出发，特别是对于管理不到位，程序员整体素质不是那么高的开发团队，采用这种方式未必能发挥其优势和功效，反而会成为制约前进的一种方式。

2.Gradle

对于gradle我是相当喜欢和推崇。但推崇不能盲目，和Maven一样拥有*仓库且支持多种仓库方式。

同样站在开发团队管理和日常开发效率、舒适度、方便程度角度出发，我建议采用gradle的maven*仓库来拆解传统jar包全在lib文件夹里的方式，是比较合理且无需太大的代价。此处的代价即人力成本、管理成本、学习成本等。

Spring3.0的几个特性，确实让人无不欣喜若狂。而其中的web fragment对java面向对象模块化开发更是给了当头一棒，立刻让人醍醐灌顶。

有人说其实java面向对象没有什么模块化开发的概念，但是java底层类库又何尝不是一种模块化开发的思想呢。

如果不用gradle、maven、fragment构建项目，也未尝不可。因为我们用来千里之外，直取上将首级的杀人工具eclipse的Deployment Assembly在一档程度上可以实现主项目引用其他项目，以模块化的思想进行调用和开发。

但有了gradle，我们可以以极小的代价去除我们长久以来的老大难：lib中的jar太多太多。多的有些让人暴躁如雷，甚至同样是log4j，却出现了不同的版本。无意中想起一首歌，“神啊，救救我吧”。

有了fragment，我们可以更加彻底的实现模块化，不仅仅分割java代码实现后台服务层组件的低耦合，前台的页面也可以实现组件化。

从第一次用svn到现在，即便是将项目转移到了git上。我依然认为svn是个不错的工具。尽管有人列举出git的种种有点而将svn贬低的一无是处。诸如git可以实现分支管理，快速回滚等等优势。

很多转向git的开发团队说出的最多的原因，可能是git可以实现版本的迭代控制、分支管理，功能特别强大。其实我想说，svn在团队管理好的情况下也可以实现类似的功能。也许工作了稍微大了些，也许需要的代价比git大了写。但是这并不能掩盖svn也是个不错的工具的事实。

那重点来了，我为什么现在将项目转移到git。其实原因很简单，我没用过git，我想要尝试新的东西，同时git 的分制管理、版本迭代的天生优势也是我迫切急需的。

Git的分支管理、版本迭代已经被大众耳熟能详了。好处就不再赘述了，我给git打99分。剩下的一分是怕他骄傲。哈哈。

大家可以登陆廖雪峰的网站，了解了解git。