I have seen a few times gradle projects split into api/impl but to date I have never seen a good information on this topic. I am talking about module like feature-something being split into

feature-something-api

that is consumed by

feature-something-impl

Does anyone have any relevant links?

What is your question about it? You can just have separate projects, one for api one for impl, or with some additional setup you could also publish them as feature variants which makes them a bit harder to consume from non-Gradle projects. Either way you would have in the consuming projects then a dependency on

api

for

implementation

and a dependency on

impl

for

runtimeOnly

. Or you could have a third module without artifacts that depends on both,

api

as

api

,

impl

as

runtimeOnly

, so that a non-Gradle consumer gets both, and a Gradle consumer would get

api

in the compile classpath and both in the runtime classpath. That latter tactic would though encourage the not fully idiomatic approach to use transitive dependencies in consumer projects which would e.g. be complained upon by the "dependency analysis gradle plugin" unless you configure it to accept it for that case. You could also just keep api and impl together and only expose the api packages using

module-info.java

so that JPMS consumers only see the api classes, and only non-JPMS consumers would still see both.