Björn Kautler

* **#1617** * **#1616** * **#1615** * **#1614** * **#1613** * **#1612** * **#1611** * **#1610** * **#1609** * **#1608** * **#1602** * **#1601** * **#1600** * **#1599** 👈 *...

Yes, something like that is what I had in mind. Just was in a rush and did not have the time to pull out an example, being confident you know...

* **#1617** * **#1616** * **#1615** * **#1614** * **#1613** * **#1612** * **#1611** * **#1610** * **#1609** * **#1608** * **#1602** * **#1601** * **#1600** 👈 * **#1599** *...

At least the dependency consistency check would really be helpful, so that `implementation` => `requires` `api` => `requires transitive` `compileOnly` => `requires static` `compileOnlyApi` => `requires static transitive` Not sure...

Currently, the plugin validates dependencies declared in build logic. In the `module-info.class` you also declare dependencies, usually the same ones as in the build logic. It can easily happen that...

Additionally to external dependencies, it would of course be awesome to get advice which JRE modules are needed in which scopes too.

> given how this project works now it'd probably be a good idea to suggest that these be implementation. I don't agree. `opens A to B` means, that `B` is...

> you can put a module-info in src/main/java9 instead of java and then it isn't supposed to affect java 8 clients. You can put it anywhere you want. The important...

> However, what you're proposing doesn’t address the root of the warning issue. Why not? I proposed to suggest `compileOnly` in that case, that should exactly fix the root of...

I didn't think that his plugin "solves" this. Yes, it has some integration with your plugin. But it requires to remove all dependencies and instead only have the module info...