java - transitive - Is there a Maven “compiler-only” scope for dependency artifacts




maven transitive dependencies (2)

I realise this is more of a semantic quest rather than a functionality quest.

I have three types of compile-scope dependencies:

  1. 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.

  2. Provided - Hibernate jars required for compilation but provided by JBoss.

  3. Compile + runtime jars.

For case 2, we could use provided scope. Case 3, we would use compile scope.

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.

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?


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:

  1. It is always necessary to load that class
    1. the class should be shipped as part of the application: <scope>compile</scope>
    2. the class should be provided by the runtime environment: <scope>provided</scope>
  2. It is sometimes necessary (because that class will be loaded only under particular circumstances): <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).


If the jars with are not true "runtime" dependencies (only for building) but not for the final artifact, you can exclude them various means:

  1. Exclusion in the assembly descriptor
  2. Exclusion in the jar (or war, ear, whatever) plugin configuration
  3. Shade Plugin minimize jar goal

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.







semantics