On 2/12/2020 1:08 PM, Robert Scholte wrote:
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.
It will lead to "split modules" on the modulepath, which will cause just
as many maintenance headaches as split packages on the classpath. Yes,
there is some maintenance benefit if a module explicitly declares that
it patches (i.e. becomes part of) another module (which might then have
to explicitly declare that it allows patching) ... but for a developer
to understand the resulting module graph requires looking at everything
on the modulepath, which is no better than having to look at everything
on the classpath. In Java, a declaration -- whether a module, a class,
or a method -- happens in one source file, and it's up to tools to
rewrite declarations if other interesting source files are known to
those tools.
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.
Is there nothing that Maven can do to make the test-compile
configuration easier to create? Maven has all the source code at its
fingertips, including knowledge of module directories which seem to
declare the same module more than once because JUnit recommends it, yet
still Maven makes the user laboriously write out the command line flags
for patching?
Alex
