RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

[Christian Stein]

Hi Alan,

the issue with modules that are provided by the run-time
image and only required at test compile- and run-time is
that with Maven you need to have the GAV (Group Id,
Artifact Id, and Version) of a dependence in order to
declare a read-edge to it. Module "java.sql" for example
can't be expressed as a GAV in the pom.xml file. Here,
the user has to resort using explicit command line
options offered by javac and java to satisfy the needs
of the "maven-compiler-plugin" and also the default
test launcher, namely "maven-surefire-plugin".

In contrast to that, all modules on the application
module path can be patched by Maven already by
using the local or external GAV coordinates.

Cheers,
Christian

On Sat, Feb 15, 2020 at 10:35 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 14/02/2020 08:02, Robert Scholte wrote:
> > :
> >
> > With a tool like Maven it is already possible to compile and run patched
> modules, but in case of requiring java.* modules it is very awkward that it
> requires additional configuration in the pom instead of some dedicated
> module descriptor, which feels most natural.
> > You'll get an exception like: package java.sql is declared in module
> java.sql, but module some.module.name does not read it
> > And the first thing that comes to mind is: add java.sql to the (main)
> module descriptor. But this should not be done.
> >
> Can you summarize how this works when compiling tests that reference
> types in modules on the application module path? Is the Maven compiler
> plugin uses `--add-modules ALL-MODULE-PATH` to include they are all
> resolved? If so, I'm just wondering about readability, do you also
> generate a list of --add-reads options too? I guess I'm just wondering
> why the issue is specific to modules that in the run-time image that
> aren't transitively required by the (unpatched) module.
>
-Alan
>