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