乱世盼英雄
现在的软件开发，比过去的软件开发要复杂得多。包括在参与开发的人数、代码规模、 复杂的需求、依赖包的复杂性、使用到更多的技术、多个项目之间的复杂依赖关系。
现在的开发人员，要掌握的技术要比过去的开发人员要多，不是现在的开发人员比以前 的开发人员本身更优秀，而是拥有更多的资料、更多的学习机会、更多更大规模的时间， 同时软件行业也在发展。说一句题外话，老程序员，如果不与时俱进，靠老本，是无法和 新一代程序员竞争的，当然，老程序员，拥有更多的经验，掌握新技术的速度更快，这又 是另外一回事。
开发人员掌握的技术更复杂了，项目用得的技术自然也是更复杂，例如一个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是非常痛苦的事情。
当然也可以不使用project依赖的方式，而使用artifact lib的依赖方式，但是 artifact lib的依赖方式，就是同时修改多个project，互相调试时带来了痛苦。
在以前，我们面临这些问题时，唯一的感觉就是，这事情TMD的太麻烦，几乎是失控了 。
maven的出现，解决这种问题看到了希望。maven出现的原因就是，现在的开发管理复杂 度达到了一定程序，需要专门的开发管理工具，这样的工具需要涵盖开发的各个阶段，包 括工程建立、配置依赖管理、编译、测试、产生分析报告、部署、产生制品等阶段。目前 ，各个阶段的工具都存在，但是不是集成的，对使用带来了很大麻烦。maven集成了这些工 具，提高了统一的环境，使得使用更简单。
现在maven非常流行了，apache上所有java project都已经build by maven，其他跟进 的开源项目非常多，例如mule、hibernat等等，商业公司也很多在采用，sun公司提供有 maven2 repository。
现在，2007年，如果你还没采用maven project，你可能需要思考一下，是否你使用了 不恰当的方式管理的代码，或者你落伍了？