>首先是传递依赖关系的问题.据了解,如果您提供依赖关系,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库.
>二是仓库的管理. Maven附带了一个默认的主存储库,但是我发现在许多情况下,这个存储库不是最新的.例如,如果你想要spring3,你必须手动添加springource存储库,如果你想要hibernate 3.5,你必须添加jboss存储库.当您必须自行追查正确的存储库时,似乎打破了自动依赖关系管理的要点.这个狩猎很快就会变得复杂.例如添加Spring3,您可能希望春季发行回购,春季外汇回购和春季里程碑式回购.
>与第2号密切相关的是确保您具有正确版本的工件.通过为给定的工件包含错误的依赖工件的版本,我已经被烧了几次.例如对于spring3的servlet / jsp / jstl apis的错误版本,或者hibernate的持久性/注释apis的错误版本.这些存储库充满了许多版本,其中有些是令人困惑的名称,如productx-3.ga,productx-3-rc1,productx-3-SNAPSHOT,productx-3-cr,product-3-beta等.其中一些是显而易见的(rc = release候选),但是尝试确定这些版本的顺序可能会令人困惑.
>最后,类型的问题依赖.我可能只是不太了解这个,但是很多repo工件是类型“pom”而不是“jar”.几次我已经在我的项目中添加了一个依赖项jar,只能在构建时找到repo jar实际不存在(例如,在jboss repo中是org.hibernate ejb3-persistence).
通过一些实验,我通常可以得到一个构建工作,但是依赖管理一般这个复杂？我仍然喜欢这种方法手动添加jar文件到我的项目,但我有兴趣了解如何提高我的maven依赖管理技能.
解决方法
>一些可移植的依赖标记是可选的,因此不需要这些功能的人不会下载它们,但需要的人必须在他们的pom中明确设置它们.> Maven Central存储库仅包含版本.因此,它不包含Hibernate 3.5(它是beta)以及它没有包含Spring 3,直到它被释放(顺便说一句,你不需要为Spring 3指定特殊的Spring仓库 – 释放已经在Maven Central)> slf4j是一种非常特殊的依赖关系,它的运行时行为取决于你使用的slf4j的实现.因此,为了控制其行为,您必须明确指定slf4j实现>关于管理技能：获取有用的信息来维护你的pom.xml,你可以使用mvn依赖：tree(尤其是-Dverbose = true)和mvn依赖关系：analyze.检查依赖关系的pom文件以查找可选依赖关系也是有用的.
