Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gno...@apache.org> a écrit :
> In my case, it was a test in mvnd which is using some low level > reflection. I do agree this is not the best example, because an easy > workaround can be done by configuring surefire to use a fork. However, if > a plugin does the same thing, there's no easy way to workaround it. > Guess the most trivial workaround is to replace the plugin by a custom exec one propagating maven current context in an extension and forking the plugin run since maven jvm customization from files is not well supported for now or would need some more advanced script which could source an optional setenv to set maven_opts but this last one would test java version which is never great to launch a build and would require to test args "the maven way" (phase, plugin:goal, plugin:goal@exec) to bypass it when possible. > Le mar. 15 juin 2021 à 19:04, Robert Scholte <rfscho...@apache.org> a > écrit : > > > AFAIK the --add-opens is only useful when using the module path. Maven > > itself and the plugins use the classpath, so I would like to have an > > example to better understand your issue. > > > > As others explained, --add-opens allow overriding the default > accessibility. For example if you get a private field on a JDK class and > use setAccessible using reflection, you may run into an exception that > would require adding this --add-opens argument on JDK 11 or more. They are > not required on JDK 8 and the annoying thing is that the option causes the > JVM to fail. > > Using forked JVM from inside plugins does work around the problem, but only > when that's possible ;-) > > > > > > thanks, > > Robert > > On 15-6-2021 18:43:35, Guillaume Nodet <gno...@apache.org> wrote: > > Hi everyone ! > > > > There are some small incompatibilities between JDK around the supported > > command line versions. Usually, those do not cause any real problems. > > However, the "--add-opens" are sometimes necessary and only supported on > > JDK >= 9, as the JVM exits with an error on JDK 8. > > Some plugins may require the use of those options when running on JDK >= > > 9. What would be the way to solve this ? > > > > For mvnd, when the client launches the daemon, the JDK_JAVA_OPTIONS > > environment property is used. But it works because we have control on the > > client environment. But when you just clone a git repo, asking the user > to > > set a specific environment is problematic imho. The .mvn/maven.config or > > .mvn/jvm.config can't be used to set up environment variables or to > > conditionally set up arguments afaik. > > > > Any idea ? > > > > -- > > ------------------------ > > Guillaume Nodet > > > > > -- > ------------------------ > Guillaume Nodet >
