A few plugins that fail with the same problem found by googling a bit: https://youtrack.jetbrains.com/issue/IDEA-266556 https://github.com/projectlombok/lombok/issues/2681
https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 That's just the first page on google... so I don't think this is me running into a corner case. JDK 16 has only been release 2 months ago, and the rules have changed quite a bit since JDK 15, so that's not an old problem, it's a new one. I think adding the --illegal-access=permit option on the command is sufficient to solve all those problems, but the problem is still the same : this option will break if using JDK 1.8. This has to be configured on the project and not globally. I'm not sure what you refer to with the setenv.sh script ? is that something that maven launcher runs prior to launching the JVM ? Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gno...@apache.org> a écrit > : > > > 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" ... :-) > > > > Got it, but point is "is it that often needed"? > Most plugin using toolchain or equivalent can have JVM customization > (already) and it is trivial to handle per jvm config through profiles. > So at the end it is only about maven "embedded" plugins and maven itself. > Last one shouldnt need anything and first ones are solved by forcing a JVM > version for the main build (which does not prevent to run tests and graalvm > native-image with 50 different JVMs). > > The setenv.sh/bat option seems like an acceptable compromise for these > border cases but not sure we need anything more fancy. > What I would be really against is a jvm.config like solution which does not > enable to use any configuration (we can't use space for example right now > in system properties so if we get the same limitation for env vars it would > be pointless IMHO). > > Hope it makes sense. > > > > > > 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 > > > -- ------------------------ Guillaume Nodet
