与maven的依赖管理

Question

我最近成为Maven的忠实粉丝,用于控制我的应用程序的构建周期.但是,我遇到了Maven依赖管理的一些粗糙边缘.我想知道这些是否是工具和范例的限制,依赖管理的必要弊端,或者我是否只是错误地使用了工具.

1. 首先是传递依赖的问题.据我了解,如果你提供一个依赖,Maven将反过来找到该依赖的任何依赖.这很好,但对于我的许多依赖项,这没有用.例如,在我的项目中包含Hibernate:

   <dependency>
       <groupId>org.hibernate</groupId>
       <artifactId>hibernate-core</artifactId>
       <version>3.3.2.GA</version>
   </dependency>
   

   导致slf4j缺少依赖性.我需要手动添加这个依赖项,我认为这将是Maven的工作.春天也是如此.如果我将Spring-MVC添加为依赖项,那么不应该为我添加所有基本的servlet依赖项(因为Spring-MVC需要这些东西)？我指的是servlet,jsp,jstl库.

2. 其次是存储库的管理.Maven附带一个默认的主存储库,但我发现在很多情况下这个存储库不是最新的.例如,如果你想要spring3,你必须手动添加springource存储库,如果你想要hibernate 3.5+,你必须添加jboss存储库.当你必须自己寻找正确的存储库时,它似乎打败了自动依赖管理的重点.这种狩猎很快变得复杂.例如,要添加Spring3,您可能需要spring release repo,spring externals repo和spring milestone repo.

3. 与数字2密切相关的是确保您拥有正确版本的工件.通过为给定的工件包含错误版本的依赖工件,我已被多次烧毁.例如,spring3的servlet/jsp/jstl apis的错误版本,或者hibernate的错误版本的持久性/注释apis.存储库中充满了许多版本,其中一些版本名称如productx-3.ga,productx-3-rc1,productx-3-SNAPSHOT,productx-3-cr,product-3-beta等等.其中一些显而易见(rc =发布候选版本),但尝试确定这些版本的顺序可能会令人困惑.

4. 最后,类型一个依赖的问题.我可能只是不太了解这一点,但许多repo工件都是"pom"而不是"jar".有几次我在项目中添加了一个依赖jar,只是为了在构建时发现repo jar实际上并不存在(例子是jboss repo中的org.hibernate ejb3-persistence).

通过一些实验,我通常可以获得一个构建工作,但一般来说依赖管理这个复杂吗？我仍然更喜欢这种方法手动将jar文件添加到我的项目中,但我有兴趣学习如何提高我的maven依赖管理技能.

Answer 1

无法回答问题的所有部分,但关于其中一些问题:

• 一些传递性依赖被标记optional,因此不需要这些功能的人不会下载它们,但是需要的人必须在他们的poms中明确地设置它们.

• Maven Central存储库仅包含版本.因此,它不包含Hibernate 3.5(它是beta)以及在它发布之前它没有包含Spring 3(顺便说一句,你不需要为Spring 3指定特殊的Spring存储库 - 释放已经在Maven Central)

• slf4j是一种非常特殊的依赖 - 它的运行时行为取决于你使用的slf4j的实现.因此,要控制其行为,您必须明确指定slf4j实现

• 关于管理技能:获取有用的信息,以便维护pom.xml你可以使用mvn dependency:tree(尤其是-Dverbose=true)和mvn dependency:analyze.检查依赖项的pom文件以查找可选的依赖项也很有用.