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

2022-09-02 03:05:57

当您有多个项目都使用同一组 JAR 库时,在每个项目中一遍又一遍地包含相同的 JAR 是很繁琐的。如果我正在做20个不同的项目,我宁愿没有20个完全相同的JAR文件。使所有这些项目(以及新项目)引用同一组JAR的最佳方法是什么?

我有一些想法,但每个都有一些缺点:

  • 将所有 JAR 放在一个文件夹中,并让每个项目在该文件夹中查找。
  • 使用 Eclipse,创建一个“用户库”,并让每个项目引用该用户库。
  • 创建一个引用每个 JAR 的“库”项目,并让每个项目引用该库项目。

答案 1

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

在加入专家的行列之前,你应该考虑一下你目前做事的方式到底有什么问题。你提到这很乏味,而且你有很多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经历带来一些结束。:)


答案 2

使用 MavenIvy 来处理这些共享的罐子。如果您担心对项目进行过多更改,只需使用 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组合所需的所有缺点也无趣。专注于编程,而不是构建。


推荐