----- Mail original -----
> De: "Alex Buckley" <alex.buck...@oracle.com>
> À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>
> Envoyé: Mardi 18 Février 2020 18:42:10
> Objet: Re: RFE simplify usage of patched module [by Robert Scholte, from
> jdk-dev]
> On 2/14/2020 9:34 PM, Christian Stein wrote:
>> Assuming `--patch-module-descriptor` was already available, the
>> org.astro test story would read:
>>
>> - org.astro/main/module-info.java:
>>
>> module org.astro {
>> exports org.astro;
>> requires java.logging;
>> }
>>
>> - org.astro/test/module-info.java:
>>
>> open /*test*/ module org.astro /*extends main module org.astro*/ {
>> requires java.sql; // system-provided module needed by test code
>> requires org.junit.jupiter; // framework reflecting entry-points
>> requires org.assertj.core; // ...and more test-related modules
>> }
>>
>> A build tool now easily may detect that `--patch-module-descriptor`
>> is required at test compile and run time. It could infer it from the
>> same module name or simply by seeing a main and a test
>> `module-info.java` compilation unit within the sources of the
>> org.astro Maven-/Gradle-/pro-/Bach-/any-build-tool-"module".
>>
>> Build tools could pass the following argument to javac/java
>> while being in their test-scope tasks. Of course, implying that
>> org.astro/test/module-info.java is the current "primary" module
>> descriptor:
>>
>> --patch-module-descriptor org.astro=org.astro/main/module-info.java
>>
>> That's it.
>>
>> The primary test-relevant modular directives are enriched by
>> those of the main module as declared in org.astro/main/module-info.java
>> resulting effectively in a synthetic in-module test module descriptor that
>> resembles the inter-module test descriptor presented above:
>>
>> - SYNTHETIC test module for org.astro
>>
>> open /*test*/ module org.astro /*extends main module org.astro*/ {
>> requires java.sql; // system-provided module needed by test code
>> requires org.junit.jupiter; // framework reflecting entry-points
>> requires org.assertj.core; // ...and more test-related modules
>> //
>> exports org.astro; // patched from org.astro/main/module-info.java
>> requires java.logging; // patched from org.astro/main/module-info.java
>> }
>
> Good description of how the main module
> (org.astro/main/module-info.java) and the test module
> (org.astro/test/module-info.java) interact to form a test-scoped module.
> 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. 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.
Hi Alex,
no you can't because you can not reconstruct a module-info from the flags
--add-modules, --add-reads, etc.
Those flags has been created to patch (mostly the JDK) module metadata so an
application using the classpath can open/patch the JDK modules metadata enough
to be able to run.
The semantics of a module-info is richer than the semantics of the flags, by
example, there is no way to define a transitive dependency or to define a
service.
I believe that roughly half of the semantics of a module-info has no equivalent
in term of flags (and for good reason, those flags have not been created to
describe a module-info).
> No need for --patch-module-descriptor in the JDK.
We need a way to express that the module graph when testing is different from
the one when running in production.
--path-module-descriptor is a way to get that.
>
> Alex
Rémi
