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

Question

当您有多个项目都使用同一组JAR库时,为每个项目反复包含相同的JAR是很繁琐的.如果我正在处理20个不同的项目,我宁愿没有20个相同的JAR文件集.使所有这些项目(以及新项目)引用同一组JAR的最佳方法是什么？

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

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

Answer 1

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

在跳上maven的潮流之前,你应该考虑以你现在的方式做事情的真正错误.你提到它很乏味,并且你周围有很多jar文件.我使用Maven在一个大型多模块项目上创建了构建过程,然后在接下来的18个月中不断地与它进行斗争.相信我这很乏味,周围有很多jar文件.

由于回到Ant并将罐子与使用它们的项目一起提供源控制,因此它的运行更顺畅.

我将一堆jar文件存储在我的机器上的一个目录中,然后当我创建一个新项目或者需要向现有项目添加一个新jar时,它只需要大约30秒:

• 将jar从JAR_REPO复制到项目lib目录.
• 将jar添加到build.properties
• 将jar添加到build.xml中的classpath
• 添加jar以在Eclipse中构建路径.

在一个项目的过程中,30秒是微不足道的,但这意味着我有一个项目可以从源代码控制中检出,只需工作,无需任何自定义Eclipse配置或Maven安装或用户特定设置.

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

更新:评论提示澄清

@Robert Munteanu:感谢您的反馈和最新评论.这可能听起来有点争论,但我担心我不能同意你Maven更简单,更清楚,或者从长远来看它会节省你的时间.

从您的帖子中可以
看出:"我坚信声明依赖关系更简单明了,而不是手动包含它们.与此相关的一次性成本很小 - 常春藤比Maven小 - 但从长远来看它确实有回报".

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

明晰

下面的两个依赖声明做同样的事情.我发现Ant比Maven更清晰.

蚂蚁风格:

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

Maven风格:

<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文件的绝对路径.您可以搜索compile.classpath的用法.你需要知道的还有很多.

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

• groupId是什么意思？
• artifactId是什么意思？
• 罐子从哪里来？
• 罐子现在在哪里？
• 提供的范围是什么？谁在提供它？
• 这个jar文件是如何在我的WAR文件中结束的？
• 为什么这个依赖项没有版本元素？
• 我不明白这个错误信息.它到底意味着什么？
• 地球上的那个jar文件来自哪里？我没有声明.
• 为什么我的classpath上有相同jar文件的2个版本？
• 为什么项目不再建造？自从我上次构建它以来没有任何改变.
• 如何添加不在Maven存储库中的第三方jar？
• 再次告诉我从哪里获得Eclipse插件.

传递依赖

"另一个更小的好处是处理传递和冲突的依赖关系."

根据我的经验,传递依赖性比它们的价值更麻烦.您最终得到了同一个jar文件的多个版本,最终得到了您不想要的可选jar文件.我最终声明了所有提供范围以避免麻烦的事情.

长期回报

"专注于编程,而不是建设."

我同意.由于源代码控制回去蚂蚁和把我的jar文件我已经能够花费远远更少的时间处理的建立问题.

这些是我花更少时间做的事情:

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

无论如何,抱歉长篇大论.也许现在我已经摆脱了我的胸膛,我可以为我漫长而痛苦的Maven体验带来一些关闭.:)

Answer 2

使用Maven或Ivy来处理这些共享jar.如果您对过多地更改项目持谨慎态度,可以使用Ivy为您管理额外的类路径.

两者都有很好的Eclipse插件:

m2eclipse的

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

IvyDE

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

我用过的效果很好.

您会注意到它们都引用工作区外的jar ,因此删除了复制.

更新(由评论提示):

我推荐这种方法的原因是我坚信,声明依赖关系然后手动包含它们会更简单,更清晰.与此相关的一次性成本很小 - 常春藤比Maven小 - 但从长远来看它确实有回报.

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