It's astonishing how many people see that both build tool config (e.g. pom.xml) and module declaration (module-info.java) list dependencies and then jump to the conclusion that one should be continuously generated from the other. This is a bad idea for a few reasons. 🧵

1. Build tool config and module declaration contain lots of information that the other couldn't care less about (e.g. module exports and services are meaningless to build tools). So to generate, you need to put a lot of information in a place, where it's useless.

@nipafx Instead, I just don't ever use the module system.

@nipafx We’d suggest using the maven or Gradle plugins @Bndtools. It solved all this a while ago. You also get decent OSGi metadata free of charge without doing anything. See: bnd.bndtools.org/chapters/330-j…

@nipafx Declaring dependencies twice (with different names and different effects at that) is an absolute no-go. A build system is a requirement. To conclude: you can't use the module-system.

@nipafx The unique module name, its version and dependencies referring to a version range belong to the code and not into a non-standard, build tool specific file. In module-info a "requires" without a version range is only valid in a closed world, as is the case for the system library.

@nipafx This is helpful insight. Modules are a thorn for a seemingly simple problem. Any light at end of this tunnel? Are there ideas to make it more pleasurable to use?