@eriwen We need to revisit that Blog post. compileOnly is only meant for exactly what it says: Things you only need at compile time. If your libraries need that dependency to work at runtime too, it should either be api or implementation, depending on whether it is part of the library’s API.
compileOnly is vastly overused in my opinion. One of the few valid use cases I can think of is annotation libraries that are only needed for compile-time checks. It can also be used as a workaround for our current lack of “optional features”, which will soon be rectified.
The “things provided by someone else” use case is modelling things the wrong way round. The library should not make assumptions about how its dependencies will be provided in the final deployment. That’s up to the consumer of the library. Ironically this is the use case that most people use it for, because that’s what you do in Maven-land with the <provided> scope (which is an equally bad model). We need some best practices documentation there for people coming from Maven.
@StefMa to summarize: Use api/implementation as applicable.