RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]
Alex Buckley
alex.buckley at oracle.com
Fri Feb 14 21:29:36 UTC 2020
On 2/14/2020 11:29 AM, Christian Stein wrote:
>> A different way to address those use cases would be to ship the
>> logic just described for `--patch-module-descriptor` in a launcher
>> offered by the test framework itself.
>
> That's too late in the build game. You already need this merged
> descriptor at compile time. And you need the user to define the
> additional elements (modifiers and directives), as no build tool
> may infer them always correctly by inspecting the test sources...
Fair point, and thanks for reminding me about your "Testing In The
Modular World" document.
The thing I'm having trouble with is that javac already lets you specify
the --add-reads options on org.junit.jupiter.api & friends that are
needed to compile test code. If Maven expects the user to painfully
configure the POM to pass --patch-module-descriptor to javac, why can't
the POM offer an easy way to make Maven itself (in the `test-compile`
phase?) pass some defined-behind-the-scenes --add-reads options?
Similarly, at run time, you propose to always open the main module to
the same org.junit.platform.commons module -- `module-info.test` is more
or less the same for every JUnit project -- so why doesn't the POM have
an easy way to let Maven itself (in the `test` phase?) pass --add-opens
to java?
There are no new modularity "primitives" here (by which I mean features
of the module system itself, such as open modules) ... there is just
detailed configuration which, in the testing context, should be done by
the build tool rather than the user.
Alex
More information about the jigsaw-dev
mailing list