Publishing plugin should respect compileOnly configuration

Help/Discuss
1

Hi,

after the addition of compileOnly configuration into Gradle I would expect that MavenPublication publishing type would respect compileOnly configuration and generate proper Maven provided scope in the generated pom file.

This is however not working in Gradle 4.0-rc-1.

Can you verify/add it to Github issues?

Thanks

2

compileOnly dependencies are only for compilation. They must never leak into clients, so there would be no point putting them into a published POM (no matter which scope).

3

That is not exactly true.

If you have a JAR file that was compiled against a specific library using compileOnly configuration, it still needs such dependency at runtime.

So once the information is missing in the generated pom.xml, you simply cannot easily use such JAR file as you would experience ClassNotFoundExceptions at runtime.

4

That would be a misuse of compileOnly. If you need it at runtime too, it should be a compile dependency.

5

You are right, will investigate why we are using such construct. Thanks

6

One case I find myself abusing compile-only is as a shortcut substitute for optional dependencies.

I.e. when a single optional feature of a library needs a dependency with large transitive closure, and we don’t want to split a separate jar.

What we ideally want to express here is “you don’t always need this dependency, but when you do it should be of version x.y.z”

7

I think the way we want to solve this in the future is making it simpler to define variants of a library (both on the producer and consumer side), so that you can model this at a higher level than “optional” and “exclude”. I.e. one problem with “optional” is that there might be multiple optional dependencies, but you need them all together if you take one of them. That gets lost in a simple “optional” flag.

Until we have that my recommendation would go in the other direction: Make them normal api/implementation dependencies and let the consumer decide if she wants to exclude or not. Or even better - make it a separate module that is discovered through Java’s ServiceLoader mechanism or similar.