java 是否有依赖工件的 Maven“仅编译器”范围
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12824112/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there a Maven "compiler-only" scope for dependency artifacts
提问by Blessed Geek
I realise this is more of a semantic quest rather than a functionality quest.
我意识到这更像是一种语义探索，而不是功能探索。
I have three types of compile-scope dependencies:
我有三种类型的编译范围依赖项：
Compile-only scope, not used at run-time. GWT client-side dev, MVP4G, RestyGWT, Source retention annotation processors. I use REST, so I don't need GWT server side.
Provided - Hibernate jars required for compilation but provided by JBoss.
Compile + runtime jars.
仅编译范围，不在运行时使用。GWT 客户端开发、MVP4G、RestyGWT、源保留注释处理器。我使用 REST，所以我不需要 GWT 服务器端。
提供 - 编译所需的 Hibernate jar，但由 JBoss 提供。
编译 + 运行时 jars。
For case 2, we could use provided scope. Case 3, we would use compile scope.
对于情况 2，我们可以使用提供的范围。情况 3，我们将使用编译范围。
However for case 1, I use provided scope, even though JBoss does not provide those files at all. Nor are they needed at run-time.
但是，对于案例 1，我使用了提供的范围，即使 JBoss 根本不提供这些文件。在运行时也不需要它们。
Anyway, don't you think Maven should provide for a synonym for "provided" for a scope where the artefacts are not really needed except at compile time? Perhaps, should there be a "compile-only" scope?
无论如何，您不认为 Maven 应该为除编译时之外真正不需要人工制品的范围提供“提供”的同义词吗？也许，应该有一个“仅编译”范围吗？
采纳答案by noahlz
If the jars with are not true "runtime" dependencies (only for building) but not for the final artifact, you can exclude them various means:
如果 jar 不是真正的“运行时”依赖项（仅用于构建）而不是用于最终工件，您可以通过各种方式排除它们：
- Exclusion in the assembly descriptor
- Exclusion in the jar (or war, ear, whatever) plugin configuration
- Shade Plugin minimize jargoal
- 程序集描述符中的排除
- 排除在 jar（或 war、ear 等）插件配置中
- 阴影插件最小化 jar目标
I agree that shipping unnecessary classes is annoying (I've seen junit and testng jars in production deployments - brrrr...), but for all practical purposes it's a rather minor one.
我同意传送不必要的类很烦人（我在生产部署中看到过 junit 和 testng jars - brrrr ...），但对于所有实际目的来说，这是一个相当小的目的。
If you have a dependency conflict (i.e shipping a "all deps" version of a library or framework), that's a different story, but doesn't sound like what you're facing here.
如果您有依赖项冲突（即发布库或框架的“所有依赖”版本），那是另一回事，但听起来不像您在这里面临的情况。
回答by meriton
Don't complain that the language does not offer fine distinctions if you only know half its vocabulary.
如果您只知道一半的词汇，请不要抱怨该语言无法提供细微的区别。
If a dependency is only used for building, such as an annotation processor, it should be a maven <plugin>, or <dependency>thereof.
如果一个依赖只用于构建，比如一个注解处理器，它应该是一个 maven <plugin>，或者<dependency>它的。
Otherwise, if it is in the compilation classpath, it will be necessary for linking the generated class file at runtime. Then, there are two cases:
否则，如果它在编译类路径中，则需要在运行时链接生成的类文件。那么，有两种情况：
- It is always necessary to load that class
- the class should be shipped as part of the application:
<scope>compile</scope> - the class should be provided by the runtime environment:
<scope>provided</scope>
- the class should be shipped as part of the application:
- It is sometimes necessary (because that class will be loaded only under particular circumstances):
<optional>true</optional>
- 总是需要加载那个类
- 该类应作为应用程序的一部分发送：
<scope>compile</scope> - 该类应由运行时环境提供：
<scope>provided</scope>
- 该类应作为应用程序的一部分发送：
- 有时是必要的（因为只有在特定情况下才会加载该类）：
<optional>true</optional>
The only option not covered is compiling a Java program, and never running it in a JVM. This is a really obscure use case, and I can't fault the designers of maven for not including a scope just to express this distinction - particularly since it is irrelevant to Maven's core responsibility (building the software).
唯一没有涉及的选项是编译 Java 程序，并且永远不要在 JVM 中运行它。这是一个非常晦涩的用例，我不能责怪 Maven 的设计者没有包含范围只是为了表达这种区别 - 特别是因为它与 Maven 的核心职责（构建软件）无关。
