将Maven中的传递依赖限制为运行时范围
我有2个使用Maven的项目。第一个是包含实用程序类和方法的库。第二个项目是将库作为依赖项的实际应用程序。我的图书馆在内部使用第三方图书馆。将Maven中的传递依赖限制为运行时范围
因此，这些都是依赖：
- 我的图书馆：依赖于第三方库
- 我的应用程序：要看我的图书馆
不过，我不希望第三方库类可在编译时间在我的应用程序。这是因为该应用程序由大型团队支持，并且我希望防止人们意外地使用应用程序中第三方库中的方法，因为某些类名称和某些方法名称在两者之间相似。当然，第三部分库将不得不在我的应用程序中可用运行时。
如果我的所有依赖项的范围是compile，它不会达到我的目标。有没有办法在Maven 3中实现这一点？
非常好的问题，不幸的是，你不能使用Maven 3或2或任何其他版本，因为它的基本设计。你所问的实际上是一个理想的和理想的行为，因为实际上任何神器的依赖关系都应该是可传递的，范围是runtime。但是，这样的设计会导致一些问题。正如你可以在Maven's Introduction to the Dependency Mechanism约compile范围阅读：
它的目的，这应该是运行时间范围，而不是，让所有 编译依赖关系必须被明确列出的 - 但是，没有图书馆在哪儿，你所依赖的 情况从另一个 库扩展一个类，迫使你在编译时可用。对于这个 的原因，编译时间依赖关系仍然是编译范围，即使它们是可传递的 。
因此，正如你所看到的，你所需要的实际上是这种行为的恰当设计，这是不幸的，不可能实现。
在过去三年中没有任何变化，所以Michal的回答仍然正确：无法限制Maven中的传递可见性。
但是，您应该考虑重新设计您的库以将其拆分为编译时依赖项所必需的api-artifact，并且它本身不依赖于第三方库和仅作为运行时依赖项需要的实现工件并依赖于第三方库。
在您的应用程序中，您可以使用“运行时”作用域声明第三方库的显式依赖项。
这可以防止在编译时看到第三方库，因此没有直接的用法可以潜入。但是，它仍然会在运行时出现（因为它是库所需要的）。
这是有效的，但很尴尬，值得在pom中解释XML注释。
其他答案是正确的。除了通过拆分出来的人造仅API模块周围周围缺少重要的特征在Maven的工作，你也有这些选择：
- 排除传递依赖，则直接取决于他们（你必须管理的版本号你自己）
- 使用checkstyle导入控件和CI。这样团队成员可以使用传递，但是然后maven验证将失败
- 使用gradle。这是Maven的 的诸多限制
您可以分析依赖一个解决方案：mvn dependency:analyze或有分析为验证生命周期阶段的一部分依赖关系： https://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html
我希望有办法做到这一点。谢谢你的回答，米哈尔。 – Juanal
这是几年前回答的。现在有什么办法可以做到这一点吗？我想知道你是否可以用'import'的范围在这里破解一个解决方案？ –
我不认为这里有什么改变。正如我在2012年所说的那样，这是非常基础的Maven设计。我相信现在没有办法改变这一点，因为Maven从一开始就是这么做的。 –