Well, my point was not really to find a workaround, but rather to start a discussion around "maven jvm customization from files is not well supported for now" ... :-)
Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > 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 > > > -- ------------------------ Guillaume Nodet
