RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]
Robert Scholte
rfscholte at apache.org
Wed Feb 12 21:08:17 UTC 2020
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.buckley at 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
More information about the jigsaw-dev
mailing list