应该是,毕竟 Maven 应该得到 libA 的依赖,但它没有。
不,在您的情况下,Maven 不会突然知道 libA 需要哪些传递依赖项,因为 libA 是手动安装的,并且在任何地方都没有 libB 的踪迹。
通常,传递依赖关系是dependencies
在文件部分中定义的依赖关系,.pom
可作为已部署应用程序的一部分。该.pom
文件本质上是原始pom.xml
文件的副本,重命名以反映库名称(即artifactId-version.jar
,然后artifactId-version.pom
)。
解析依赖项时,maven 还将检查其.pom
文件,并因此获取有关其依赖项(成为传递依赖项)的信息,并为其构建(并获取)所需的依赖关系图(即,为每个和重新迭代相同的过程)每个声明的依赖项)。
来自官方Maven——依赖机制介绍
通过从指定的远程存储库中读取依赖项的项目文件,可以促进此功能。通常,这些项目的所有依赖项都在您的项目中使用,项目从其父项或从其依赖项等继承的任何依赖项也是如此。
注意:粗体是我的。项目文件通常是文件,一旦相关工件上传到 Maven 存储库(或安装到本地 Maven 缓存中) ,就会pom.xml
重命名为文件。*.pom
根据您的问题,您使用-DgeneratePom=true
了 ,因此您没有传递 libA'文件,而是自动生成pom.xml
了一个新文件
如果没有通过参数提供,则为工件生成最小 POM pomFile
。true
如果本地存储库中还没有现有的 POM,则默认为。
自动生成的.pom
文件几乎是空的(Maven 坐标 (groupId, artifactId, version) 但其中没有dependencies
部分),因此 Maven 会将 libA 视为没有传递依赖关系的库:它找不到任何内容,也无法猜测。
因此,您有四种解决方案(按推荐顺序):
- 在企业环境中,设置企业 Maven 存储库(如 Arifactory、Nexus 或 Apache Archivia)并将这些库正确部署到其中,或者
- 使用该选项重新安装 libA
pomFile
,或
- 手动将该
dependencies
部分添加到生成的.pom
文件中并将 libB 添加到其中,或者
pom.xml
在您的使用者文件中明确声明 libB
如需进一步阅读 SO: