我在协调构建项目以在应用程序服务器中使用和用作独立应用程序时遇到问题。
为了给出一个整体简化的上下文，假设我有三个项目 A、B、C。
项目 A 依赖于项目 B，项目 B 又依赖于项目 C。
项目 C 有一个依赖项 X，它被标记为已提供，因为预计它将在应用程序服务器中作为 JEE 库提供。即jms.jar。
因此，如果我执行项目 A 的程序集构建，我会得到所有传递依赖项，除了那些标记为按预期提供的那些。
现在我有一个新的部署方案，项目 A 需要在独立环境中使用，即在应用程序服务器之外。
所以现在我需要 jms jar 作为编译依赖项。这是否意味着我应该在项目 A 中显式添加 X 的编译依赖项？这是否违反了得墨忒耳法则，即不要与陌生人交谈，从某种意义上说，项目 A 不应该明确知道项目 C，而只知道项目 B？
这是一个简单的示例，但实际上我有多个已标记为已提供但现在需要编译或运行时依赖项的依赖项，因此它们最终出现在 maven 程序集插件生成的工件中。
这是 Maven 的一个基本问题还是我没有正确使用这些工具？
提前感谢您的任何指导。
如果您需要您的构建针对不同的场景进行变化，您需要使用配置文件并在各种配置文件中保留某些内容（例如某些依赖项）。
http://maven.apache.org/pom.html#Profiles
回答了一个类似的问题 - 但您可以将“项目 A”和“项目 C”的“发布”和“调试”交换
提供的依赖是一个困难的主题。首先：提供的依赖项在以下意义上是不可传递的：如果您的项目 C 对 X 具有提供的依赖项，那么 A 将不会获得该依赖项。它被默默地忽略。这符合我提出的“提供”的以下含义：
只有实际部署的工件才应将依赖项标记为“已提供”。未单独部署到特定服务器的库或其他 jar 不应该提供依赖项。相反，它们应该将它们的依赖项声明为编译依赖项。在您的示例中：项目 C 应该对 X 具有编译依赖项。如果项目 A 知道提供了 X，则它将 X 设置为在“dependencyManagement”中提供。由于项目 A 应该知道它运行的环境，它应该决定提供什么，不提供什么。而“dependenyManagement”是声明这一点的正确位置。
如果您的项目 A 应该能够在给定的服务器内部和外部运行，您可能需要进行大量调整，甚至将类型从 ear 更改为 jar。因此，您要么为此使用构建配置文件，然后具有不同的 dependencyManagement 条目，要么将 A 拆分为两个项目，这些项目依赖于包含公共元素的其他项目。
如果某个给定的项目 C 已经提供了对 X 的依赖项并且您无法更改它，这实际上与 C 中缺少的依赖项相同。这必须在某个时候修复，这可能是项目 A 本身。