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.bate...@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 >
