实际上，所有软件开发项目都必须依靠来自其他项目的源代码。例如，许多项目可能依靠 log4j 等日志记录工具和 Struts 之类的 Web 框架。您的开发团队不会维护其他项目的源代码，但要依靠其 API 来实现项目中的定制软件。您的软件所依靠的其他项目数量越多（包括这些项目自身的依赖项），构建软件就变得越复杂。
我已经看到许多团队使用各种不完善的技术，尝试解决这种难题：
将全部有依赖关系的项目（JAR 文件）放在一个目录中，此目录将签入项目的版本控制存储库。这种技术不必要地增加了存储库的大小，使得管理版本差异极为困难。
将有依赖关系的 JAR 分配到一个公共文件服务器上，使团队无法控制版本更改。
手动将 JAR 文件复制到各开发人员工作站上的指定位置。这种方法使得确定丢失的文件或修正版本极为困难。
执行一条 HTTP Get命令，将文件下载到开发人员的工作站，手动执行或将其作为自动构建的一部分。这种技术会造成未受管理的 JAR 文件。
我参加过一个中型项目，包含 1,000 个 Java 类和 100 多个有依赖关系的 JAR 文件。（我们选择了第一种不完美的技术：将所有 JAR 签入项目的版本控制存储库。）
图 1 显示了可能在此类项目中看到的一小部分依赖项的类型：
图 1 表现出，Brewery 项目的源代码依赖于 Hibernate、Struts 2、MySQL Connector 和 Cobertura。而 Cobertura 又依赖其他 JAR，如 asm-2.2.1.jar、jakarta-oro-2.0.8.jar 和 log4j-1.2.9.jar。此外，asm-2.2.1.jar 依赖 asm-tree-2.2.1.jar。这仅仅是可能出现的各类嵌套依赖项的一个简单示例。即便是某个 JAR 的版本不正确，您也会体验到难以排除的问题，例如编译错误或意料之外的行为。
Apache Maven 构建管理和项目管理工具已经吸引了 Java 开发人员的注意。Maven 引入了 JAR 文件公共存储库的概念，可通过公开的 Web 服务器访问（称为 ibiblio）。Maven 的方法减少了 JAR 文件膨胀的情况，不会占用大多数版本控制存储库。但使用 Maven 时，它会鼓励您采用其 “惯例优于配置” 的方法来构建软件，这会制约您定制构建脚本的灵活性。
如果您多年来一直使用 Apache Ant，现在希望获得使用公共存储库的优势，又该如呢？您是否不得不接受 Maven 的构建方法来获得这些收益？幸运的是，答案是否定的，这是由于一种称为 Apache Ivy 的工具 —Ant 的一个子项目。Ivy 提供了最一致、可重复、易于维护的方法，来管理项目的所有构建依赖项（在 参考资料部分中可以找到 Maven 和 Ivy 的比较）。