Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gno...@apache.org> a écrit :
> 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. > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - understand we can't have the correct jpms options by default since we'll never know all plugins. > > 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. > This will likely break soon so I wouldn't consider it as an option. > > 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 ? > Yes, it is often used in servers (thinking to tomcat or karaf). mvn.sh (similarly for .bat flavor) would source bin/setenv.sh (bat) if exists. this script would container any logic the user wants and be usable to setup maven env vars before the script reads it. a common (trivial) setup would be (a more advanced can test java --version): bin/setenv.sh: #! /bin/sh epxort MAVEN_OPTS=--illegal-access=permit > > 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 >
