On 2/19/2020 3:46 AM, Christian Stein wrote:
On Tue, Feb 18, 2020 at 6:42 PM Alex Buckley <alex.buck...@oracle.com>
wrote:
Good description of how the main module
[...]
etc. Then, the build tool can enrich the main module by passing
--add-modules, --add-reads, and --add-opens to javac/java while in a
test scope. No need for --patch-module-descriptor in the JDK.
But, as Robert already noted, each build tool will come up with
a different notation for their users to configure those additional
elements. That's nothing wrong with it per se -- just that there's
already a common notation for providing modular information:
"module-info.java"
And it's hard to explain why users may write "module-info.java"
files for inter-module testing that build pass 1:1 to javac and
friends -- have to either, depending on the tool, supply:
- command-line flags... [Maven]
- or a module-info.test file... [Gradle via Plugin]
- or module-info.java file... [Pro, Bach.java]
- or some-other-module-layer-magic configuration...
only for in-module testing.
I don't know how you concluded any of the above. I explicitly said (and
you removed from the quote) that: "If a build tool has detected the
presence of the test module, then the build tool can use
javax.lang.model.element.ModuleElement to inspect the test module's
declaration and infer what it requires, whether it's open, etc." --
"test module's declaration" means "org.astro/test/module-info.java".
That is, if a test framework intends that a test module has a
module-info.java file to augment the main module's module-info.java file
(and maybe not all test frameworks want to work like that...), then a
build tool plugin for that test framework is well able to inspect the
former file and turn it into command line options for javac/java in the
test scope. The JDK isn't in the business of standardizing test
framework practices, and already provides the APIs you need to implement
any practice you like.
Alex
