当前位置: 首页 > 面试题库 >

如何获取Maven依赖项列表以及从中获取它们的存储库

颜修明
2023-03-14
问题内容

在给定pom.xml文件的情况下,我想扩展可传递依赖关系,并针对每个直接和可传递依赖关系,列出maven从中获取它的存储库。

随着maven-dependency-plugin我可以做

mvn dependency:tree 获取传递依赖关系树,但不包含存储库信息

mvn dependency:list-repositories 获取使用的存储库列表,但不包括依赖项信息

mvn dependency:get -Dartifact=<...>
来获取单个工件和可传递依赖项,但似乎获取了很多东西,我无法确定我真正关心的是哪一个。


问题答案:

我认为没有插件可以做到这一点。我认为这样做的原因是,没有人真正对这种信息感兴趣。

考虑对 发布的
工件具有依赖性。一旦将它们下载到您的本地存储库中,Maven将不再为再次下载它们而烦恼(除非您删除它们)。该工件的所有将来解决方案都将通过本地存储库进行。

当然,_remote.repositories您本地存储库的工件目录中的文件将包含从其下载的存储库的 符号
名称,随着时间的推移,其实际URL可能相同或不同。

这样的哲学是Maven坐标是全局的。例如,给定的(say)版本commons-codec:commons- codec:1.10必须相同,无论它来自何处。否则,如果某些发行版根据其来源不同而有所不同,那么一切都会崩溃。因此,没有人会在乎依赖来自何处。

快照依赖关系是另一回事,但是您不应该太依赖它们,因为您不想基于将来可能会改变的依赖关系来发布您的东西。通常情况下,你是在哪里你希望你的快照依赖于来自控制,所以查不到的整点
在那里 你的依赖来自变成徒劳。

但是有时,传递性依赖项将包括POM,这些POM为Maven指定其他存储库以从中获取子依赖项。有时,这些存储库将被分解或终止使用,从而破坏了依赖链。在这种情况下,您可能想在中屏蔽或重新路由它们settings.xml。只需对本地存储库中的所有POM进行简单扫描就足以嗅探到它们:

# Linux/Unix
%> find <your local repo> -name '*.pom' | xargs grep -c '<repositories>' | grep -v ':0'

这与和一起mvn dependency:tree应该足以确定传递依赖是否依赖于行为异常的存储库。



 类似资料:
  • cytoscape.org/nexus/的链接是:http://code.cytoscape.org/nexus/content/repositories/releases/org/cytoscape/vizmap-api/3.6.0/

  • 执行 gradle dependencies 命令会列出项目的依赖列表, 所有依赖会根据任务区分,以树型结构展示出来. 如下例: 例 11.13. 获取依赖信息 gradle -q dependencies api:dependencies webapp:dependencies 的输出结果 > gradle -q dependencies api:dependencies webapp:depe

  • 有没有可能从maven artifactory存储库中获得特定版本的依赖项JAR,谁在构建之后已经“提供”了范围。由于如此多的webapps,并且它们中的大多数都具有公共依赖项,所以考虑将所有依赖项都设置为“提供”(这样web-inf/lib将为空),并且在部署期间从artifactory存储库中获得所有特定版本的“提供”JAR(部署的第一步是将JAR复制到Tomcat公共库,然后是war部署)。

  • 我正试图让maven下载所有的依赖项(编译、测试、插件等)。)这样我就可以避免让我们的dockerized构建浪费不必要的时间一遍又一遍地下载它们。 我们已经对maven build进行了dockerized,这样我们就可以从jenkins运行它,而无需在jenkins机器上安装大量构建特定的依赖项(Java、redis、maven依赖项等)。我们的构建依赖于增量docker构建,它只执行实际需要

  • 问题内容: 如何以编程方式在Maven执行环境之外获取Maven模块的所有依赖关系? 到目前为止,我有: 通过maven-core: 并通过jcabi-aether: 到目前为止,这通常正确吗? 现在的问题是,我得到了NullPointerException: 因为mavenProject.getRemoteProjectRepositories()返回null。 如何在考虑settings.xm

  • Maven将使用其最近的WINS策略自动解决依赖关系冲突,在这种情况下,它将在结果: [INFO]-(commons-collections:commons-collections:jar:2.1:compile-因与2.0冲突而省略) 在本例中,如果选择commons-collections:2.1,我将有一个备用依赖关系树,可能包含多个其他依赖关系。 我目前正在做的工作是识别与其他依赖项有冲突