It is kind of unfortunate that this topic has been hijacked for something I don't see as an issue. I've been able to build up the right set of commandline arguments for this case for both javac and java
With *just* the dependencies(respecting compile + test scope) from the pom, and the module descriptor I've been able to compile the main/test sources and run the tests. However, recently I've informed by this case: if the test sources use one of the java.* modules (that are not used by the main sources) the only correct way to solve it now is by adding the required flags by hand (and only to the test-compile configuration!). This is hard to explain and instead of diving into the specifications, understanding what's happening, you'll see that they choose for the easy workaround: add this "test scoped" module as a required module to the module descriptor. In the end this will do more harm than good. A bit off-topic, but with Maven we already see that adding dependencies is simple, however cleaning up unused dependencies is not. Hence the exclude-option for dependencies is used frequently. Unlike Maven dependencies, you cannot exclude required modules, so here it is even more important that the list of required modules is the minimum required list. To prevent these workarounds and to provide an easier way to patch a module via a dedicated descriptor will help keeping the module system cleaner. I'm very pleased I've been able to hide most logic behind the required flags. This is a valid use case and in my opinion deserves a solution without explicit knowledge of these flags by the enduser (a tool like Maven should solve this, but this can only be done if it has access to this information.) Introducing an extra modifier looks like one solution, maybe there is a better one. thanks, Robert On 10-2-2020 23:03:28, Alex Buckley <alex.buck...@oracle.com> wrote: Hi Christian, On 2/7/2020 4:41 AM, Christian Stein wrote: > This time, I created a project at [0] with a detailed description on its > front page, i.e the README.md file. > > [0]: https://github.com/sormuras/java-module-patching To restate: - You're saying that, today, it's brittle to copy directives from src/org.astro/main/java/module-info.java to src/org.astro/test/java/module-info.java. (And having copied them, you still need to `open` the test module and add some `requires`.) - You suggest that, in future, there will still be a src/org.astro/test/java/module-info.java file which is of interest to test frameworks. What you're hoping is that new syntax will let you invert the patching: - Today, you set the module-path so that out/modules/test/org.astro.jar is the "primary" version of the module; then you redefine everything in it except module-info by overlaying out/modules/main/org.astro.jar. - In future, you want to have out/modules/main/org.astro.jar as the "primary" version, and redefine only its module-info by specifying the sidecar out/modules/test/org.astro.jar. The sidecar would have some syntax to identify that its declaration of org.astro is strictly additive to the "primary" version. You would set the module-path to out/modules/main:out/modules/test:lib so that the module system (1) finds the "primary" version in out/modules/main and (2) augments its module-info with sidecars found in out/modules/test and lib. I assume some new command line option would enable or enumerate the sidecars explicitly, because obviously the dependences and exports of out/modules/main/org.astro.jar shouldn't depend on which JAR files happen to be lurking deep in the module-path. Stepping back, the core issue is that once the true "primary" version of a module is built -- out/modules/main/org.astro.jar -- you don't want to change it. No build or test tool wants to physically rewrite its module-info to require test-time dependencies at test time, and then to not require such dependencies at release time. You want the module system to virtually rewrite the module-info instead. And that's already possible, as long as you put on your test-colored sunglasses and view out/modules/test/org.astro.jar as the "primary" version, and out/modules/main/org.astro.jar as the overlay ... once the tests have run, go back to viewing out/modules/main/org.astro.jar as the "primary" version. Introducing a new kind of module descriptor, with merging by the module system according to new command line options, seems like a lot of overhead that can already be worked around by tools at test-time. Alex
