Is there a Maven "compiler-only" scope for dependency artifacts

Question

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?

Answer 1

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

Answer 2

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.