Feature Idea: optionally allow to derive runtimeOnly dependencies using Services

[TheGoesen]

Usecase: javas services (SPI) allows to to declare services (uses xxx) and provide these services (provides xxx with yyy)
These are usually effectively runtimeOnly dependencies.
So if a project a uses service "myService" and project b provides "myService" with "ServiceImpl" project a shall have a runtimeOnly dependency on project b.

Considerations:

1. this might not always be true: For testing purposes there might be a "dummyService" which should not be a productive runtimeOnly Dependency.
2. Services can also be be declared using the classloader way of putting a file in your META-INF (probably no good implementation possible/needed)
3. The way parsing is currently handled-> see Improve parsing of module-info #175

[jjohannes]

This is an interesting idea. If you find the time, can you provide a full example project that shows which runtime dependency would be automatically added? I am a bit unclear on how exactly this would work. It would require to look at all known module-info files and cross-reference them, right? Which is technically possible now when we parse all files during initialization time (in settings plugin).

Regarding the considerations:

1. If this feature is realized, it probably needs configuration options to opt-in / opt-out. Would be good to clarify the different use cases in examples/tests.
2. I think this can be ignored.
3. Yes, Improve parsing of module-info #175 needs to be solved alongside this. It's also an option to extend the existing "line-by-line" parser to pick up additional information. Even if it is incomplete, it could be an intial solution to have something to experiment on this feature.

[TheGoesen]

agreed on all accounts.
-> yes this can only work if all module-infos are parsed at startup

[TheGoesen]

I created https://github.com/TheGoesen/serviceExample
In order for gradle run to succeed the runtimeOnly dependency in app is required, but it could be derived automatically.