在多个项目之间共享 JAR 的最佳方式是什么？

信不信由你，你的“乏味”方法可能是最简单，最干净，最耗时的方法。

在加入专家的行列之前，你应该考虑一下你目前做事的方式到底有什么问题。你提到这很乏味，而且你有很多jar文件。我使用Maven在一个大型多模块项目上创建了构建过程，然后在接下来的18个月里不断与它作斗争。相信我，这很乏味，周围有很多jar文件。

自从回到 Ant 并将 jar 与使用它们的项目一起提交源代码管理以来，它的旅程更加顺畅。

我将一堆jar文件存储在计算机上的单个目录中，然后当我创建新项目或需要将新jar添加到现有项目时，只需大约30秒：

• 将 jar 从 JAR_REPO 复制到 project lib dir。
• 添加 jar 以构建属性
• 在构建过程中将 jar 添加到类路径.xml
• 添加 jar 以在 Eclipse 中构建路径。

在项目过程中，这30秒是微不足道的，但这意味着我有一个项目可以从源代码管理中签出，并且只需要任何自定义Eclipse配置或Maven安装或用户特定的设置即可工作。

这种方法为我和我的项目团队节省了大量的时间，主要是因为它简单，可靠且易于理解。

更新：评论提示的澄清

@Robert Munteanu：感谢您的反馈和更新的评论。这可能听起来有点争论，但恐怕我不能同意你的观点，即Maven更简单，更清晰，或者从长远来看它会节省你的时间。

从你的帖子中：
“我坚信，声明依赖项比手动包含它们更简单，更清晰。与此相关的一次性成本很小 - 常春藤比Maven小 - 但从长远来看，它确实得到了回报。

让Maven为您下载jar文件可能比自己下载更容易，但这是唯一的优势。否则，Maven不会更简单，更不清楚，从长远来看，它的复杂性和局限性将使您付出代价。

清晰

下面的两个依赖项声明执行相同的操作。我发现蚂蚁的那个比Maven的要清晰得多。

蚂蚁风格：

<path id="compile.classpath">  
    <pathelement location="${log4j.jar}" />
    <pathelement location="${spring.jar}" />
</path>  

专家风格：

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>${log4j.version}</version>
    <scope>compile</scope>
</dependency>

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring</artifactId>
    <version>${spring.version}</version>
    <scope>compile</scope>
</dependency>

单纯

使用 Ant 版本，您可以将鼠标悬停在 ${log4j.jar} 属性上，它将显示 jar 文件的绝对路径。您可以搜索编译.classpath 的用法。您需要知道的并不多。

毫无疑问，Maven比我建议的方法更复杂。当你开始使用Maven时，这些只是一些需要回答的问题。

• groupId 是什么意思？
• artifactId是什么意思？
• 罐子从哪里来？
• 罐子现在在哪里？
• 提供的范围是什么？谁在提供它？
• 那个jar文件是如何进入我的WAR文件的？
• 为什么此依赖项没有版本元素？
• 我不明白这个错误消息。这到底是什么意思？
• 那个罐子文件到底是从哪里来的？我没有宣布。
• 为什么我的类路径上有同一 jar 文件的 2 个版本？
• 为什么项目不再生成？自从我上次建造它以来，一切都没有改变。
• 如何添加不在 Maven 存储库中的第三方 jar？
• 再次告诉我我从哪里得到Eclipse插件。

传递依赖关系

“另一个较小的好处是处理可传递和冲突的依赖关系。

根据我的经验，传递依赖关系比它们的价值更麻烦。您最终会得到同一 jar 文件的多个版本，最终得到您不需要的可选 jar 文件。我最终声明了几乎所有具有提供范围的内容，以避免麻烦。

长期回报

“专注于编程，而不是构建。

我同意。自从回到 Ant 并将我的 jar 文件放入源代码管理以来，我能够花更少的时间来处理构建问题。

这些是我花在花较少时间做的事情：

• 阅读可怜的Maven文档。
• 阅读更差的Codehaus Mojo文档。
• 设置共享的内部存储库。
• 教育团队成员。
• 编写Maven插件以填补空白。
• 尝试解决有缺陷的插件（发布，组装）。
• 为 Maven 安装 Eclipse 插件。
• 等待插件让我重新控制Eclipse。

无论如何，很抱歉长篇大论。也许现在我已经从我的胸口上取下了它，我可以为我漫长而痛苦的Maven经历带来一些结束。:)

使用 Maven 或 Ivy 来处理这些共享的罐子。如果您担心对项目进行过多更改，只需使用 Ivy 为您管理额外的类路径即可。

两者都有很好的Eclipse插件：

m2eclipse

Maven 类路径容器 http://img229.imageshack.us/img229/4848/mavendependencies.png

常春藤

IvyDE 类路径容器 http://img76.imageshack.us/img76/3180/cpnode.jpg

我已经使用了很好的效果。

您会注意到，它们都是工作区外部的引用 jar，因此删除了重复项。

更新（由评论提示）：

我推荐这种方法的原因是，我坚信声明依赖项比手动包含依赖项更简单，更清晰。与此相关的一次性成本很小 - 常春藤比Maven小 - 但从长远来看，它确实得到了回报。

另一个较小的好处是处理传递和冲突的依赖项。很容易忘记为什么在类路径中需要 commons-logging-1.1.jar，以及是否需要升级到 1.1.1。而且，拉入例如Hibernate + Annotation + Spring组合所需的所有缺点也无趣。专注于编程，而不是构建。