// Hope this email will be technically associated as a reply for the // "RFE simplify usage of patched module" thread.
I agree with Robert that a user-friendly and (build) tool-agnostic way to express additional module directives and modifiers for testing purposes only is ... a good thing to have. As a workaround, I proposed, implemented and promoted a tool-agnostic `module-info.test` file in [0] which, as of today, I no longer really like that much. The standard javac/java command options and arguments listed as plain text lines in that file require users to know the module-related options of javac/java meant to be primarily used by (build) tools. Perhaps this discussion leads to a solution that supersedes the purpose of "module-info.test" and renders https://youtrack.jetbrains.com/issue/IDEA-222831 as no longer needed. Robert Scholte wrote in > http://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003880.html > > [...] > What might have helped would be something like this: > src/test/java/module-info.java > [....] { > requires java.sql; > } > > I've put [...] on purpose, because in this case I don't think the module > should have the same name as the "main" module descriptor, because it > is that module. [...] > This "solution" already works today. As described in [0] you may use the existing module-info.java-DSL to describe such an additions (of extra modules needed for testing) by (I) repeating (most) directives from the "main" module descriptor and (II) add those needed for testing. This includes adding more module modifiers, like `open` as well. Using the same module name as `src/main/java/module-info.java`, of course. > One solution that might fit here is the introduction of a new modifier: > patch > patch module some.module { > > requires java.sql; > } > This describes clear the purpose of the module, and as the "patch" already > implies: it should be handled with care. [...] > Such a modifier would remedy the need to repeat directives from the "main" module. It would effectively render step (I) from above not longer required. Quote from [0]: > Note: Copying parts from the main module descriptor manually is brittle. > The “Java 9 compatible build tool” pro[1] solves this by auto-merging a > main and test module descriptor on-the-fly. Robert, you chose `some.module` as the name in this example? Is it the same name as the "main" module? Cheers, Christian [0]: https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world#white-box-modular-testing-with-module-infojava [1]: https://github.com/forax/pro
