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.

2. The reason for that is that build tools and module system serve *very* different purposes. Tasking one with generating the config for the other is a superb example for coupling mostly unrelated responsibilities. We know where that leads.

3. Letting build tools generate declarations isn't as trivial as it sounds (sitepoint.com/maven-cannot-g…). It would also need to be reimplemented by every build tool and IDE/build tool integration (or do you want to run our build tool, every time you add an `exports`?).

4. Speaking of IDEs, to get IDE support for editing module declarations, they would have to understand what part of each build tools' config contains the modules part. More effort duplicated across different projects.

5. All of that would add a considerable amount of complexity to an already challenging problem (modularity) and a non-trivial technical system (Java module system). More places for bugs to hide and more opportunities to misunderstand and get lost.

6. Having an auto-generated declaration makes it much less likely that you benefit from one of the biggest benefits of modules: Using a single-source-file description of your entire (sub)project. medium.com/97-things/take…

That's just the first half dozen off the top of my head. I'm sure there are more. And in case you're limiting the proposal to partial generation ("just the ~t̶i̶p̶~ `requires` directives"), 3.-6. apply there as well (to a lesser degree).