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,
If the jars with are not true "runtime" dependencies (only for building) but not for the final artifact, you can exclude them various means:
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.
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.
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.
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:
<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).