This message was deleted.

The problem with either optional or provided is that it won't be in the compile classpath and users would have to add it explicitly. Compare that to the current situation where things Just Work™, you might have some JAR at runtime that didn't expect, and you could re-declare the dependency as provided or optional to get rid of it, or use some sort of filtering when assembling your distribution (e.g. WAR file). Generally, compileOnlyApi are annotations that are needed by annotation processors or other static analysis tools, so they're harmless on the runtime classpath, but would break builds if absent from the compile classpath.

It's been like that since I started using Gradle, but ai thought it was a limitation on the pom.xml

@CristianGM you are not using Gradle longer than 6.7? I thought I've seen you around here earlier

I started with Gradle when Android did... Gradle 3?

Ah, ok, just wondered. Because

compileOnlyApi

was introduced with 6.7 🙂

the problem is that putting it with scope

compile

is totally unexpected for me, since it must not appear at runtime

Well, another of those shortcomings of the POM model I guess and Gradle guys had to make a decision how to map it.

yes but my question is whether it's intentional or not, since the current mapping is the default

I can only guess of course, but according to the 6.7 release notes, the intention of it is to combine compileOnly i. e. only available at compile time with api i. e. available to consumer. So for the POM model, the nearest is to put it in the

compile

scope, as it is then available at compile time of the consumer. The alternative would be to have it e. g.

optional

which then would mean it is not available to the consumer. In most cases a superfluous dependency at runtime does not hurt, but a missing dependency at compile time makes compilation fail. So to me this mapping the POM makes the closest sense given the limited possibilities. So my plain gut-feeling guess is yes, it is intentional. 🙂

in my case the superfluous dependency is hurting a lot

I guess that's a case for manual POM manipulation using

withXml

then.

Just as info: Technically, the problem is not

compileOnlyApi

but the general way how dependencies that end up only in the

apiElements

variant (and not the

runtimeElements

) are mapped. That was introduced long before 6.7 (5.x something I guess). compileOnlyApi was only added as convenience in 6.7 (you could easily add that yourself in earlier Gradle version). I guess Gradle could introduce something in the pom mapping tom make this configurable when you configure the component. I think there is no universal “right way” to do it. POM is just too limited 😕

Indeed. A similar problem happens with test fixtures dependencies, which are rightfully published as "optional" because test fixtures are implemented as feature variants. However in practice, it's not clear that you actually want that to appear in the generated pom.

Mh… yes from that perspective it would probably be more consistent if things that are only in “apiElements” would be marked as “optional” as well (if in doubt, publish less information in the POM…). But I guess we did not think about this case back then 🙂

the world would be a better place without pom.xml 🙂