You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2021/06/15 16:43:18 UTC
Supporting building with incompatible JDK versions on a single project
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
Re: Supporting building with incompatible JDK versions on a single project
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
There are two levels for me:
1. Maven itself -> maven opts works not bad but we should work ootb
2. Forks -> each plugin must support that and it cna be made dynamic with
an extension which autoadjust the conf block
Wdyt?
Le mar. 15 juin 2021 à 22:02, Benjamin Marwell <bm...@apache.org> a
écrit :
> Hi Tamás,
>
> So hazelcast runs in the module path. Maven used the class path only. Thus,
> add-opens does not do anything.
>
> UNLESS... you start sub pocesses from Maven, eg using the exec plugin.
>
> This means we still need an example where you have this issue with Maven.
>
> On Tue, 15 Jun 2021, 20:27 Tamás Cservenák, <ta...@cservenak.net> wrote:
>
> > Or xstream for that matter...
> >
> > ToP
> >
> > On Tue, Jun 15, 2021, 20:26 Tamás Cservenák <ta...@cservenak.net> wrote:
> >
> > > Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what
> > it
> > > needs to be opened up.
> > >
> > > T on phone
> > >
> > > On Tue, Jun 15, 2021, 20:19 Benjamin Marwell <bm...@apache.org>
> > wrote:
> > >
> > >> Tamás,
> > >>
> > >> which module do you open?
> > >>
> > >> In most cases I have encountered, adding jaxb as a dependency to the
> > >> project is sufficient. But to be sure, we would need to see an
> example.
> > >>
> > >> I think this would have long been noticed if it was a common problem.
> > >>
> > >> Ben
> > >>
> > >>
> > >> On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, <ta...@cservenak.net>
> > wrote:
> > >>
> > >> > Howdy,
> > >> >
> > >> > Robert, I think you are wrong:
> > >> >
> > >> > from Java 11 migration guide
> > >> >
> > >> > --add-opens
> > >> > If you have to allow code on the class path to do deep reflection to
> > >> access
> > >> > nonpublic members, then use the --add-opens runtime option.
> > >> > Some libraries do deep reflection, meaning setAccessible(true), so
> > they
> > >> can
> > >> > access all members, including private ones. You can grant this
> access
> > >> using
> > >> > the --add-opens option on the java command line. No warning messages
> > are
> > >> > generated as a result of using this option.
> > >> >
> > >> > Hence, it is needed even for CP applications, that do require "deep
> > >> > reflection".
> > >> >
> > >> > HTH
> > >> > Tamas
> > >> >
> > >> > On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <
> rfscholte@apache.org>
> > >> > wrote:
> > >> >
> > >> > > 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.
> > >> > >
> > >> > > thanks,
> > >> > > Robert
> > >> > > On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Benjamin Marwell <bm...@apache.org>.
Hi Tamás,
So hazelcast runs in the module path. Maven used the class path only. Thus,
add-opens does not do anything.
UNLESS... you start sub pocesses from Maven, eg using the exec plugin.
This means we still need an example where you have this issue with Maven.
On Tue, 15 Jun 2021, 20:27 Tamás Cservenák, <ta...@cservenak.net> wrote:
> Or xstream for that matter...
>
> ToP
>
> On Tue, Jun 15, 2021, 20:26 Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what
> it
> > needs to be opened up.
> >
> > T on phone
> >
> > On Tue, Jun 15, 2021, 20:19 Benjamin Marwell <bm...@apache.org>
> wrote:
> >
> >> Tamás,
> >>
> >> which module do you open?
> >>
> >> In most cases I have encountered, adding jaxb as a dependency to the
> >> project is sufficient. But to be sure, we would need to see an example.
> >>
> >> I think this would have long been noticed if it was a common problem.
> >>
> >> Ben
> >>
> >>
> >> On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, <ta...@cservenak.net>
> wrote:
> >>
> >> > Howdy,
> >> >
> >> > Robert, I think you are wrong:
> >> >
> >> > from Java 11 migration guide
> >> >
> >> > --add-opens
> >> > If you have to allow code on the class path to do deep reflection to
> >> access
> >> > nonpublic members, then use the --add-opens runtime option.
> >> > Some libraries do deep reflection, meaning setAccessible(true), so
> they
> >> can
> >> > access all members, including private ones. You can grant this access
> >> using
> >> > the --add-opens option on the java command line. No warning messages
> are
> >> > generated as a result of using this option.
> >> >
> >> > Hence, it is needed even for CP applications, that do require "deep
> >> > reflection".
> >> >
> >> > HTH
> >> > Tamas
> >> >
> >> > On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <rf...@apache.org>
> >> > wrote:
> >> >
> >> > > 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.
> >> > >
> >> > > thanks,
> >> > > Robert
> >> > > On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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
> >> > >
> >> >
> >>
> >
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Tamás Cservenák <ta...@cservenak.net>.
Or xstream for that matter...
ToP
On Tue, Jun 15, 2021, 20:26 Tamás Cservenák <ta...@cservenak.net> wrote:
> Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what it
> needs to be opened up.
>
> T on phone
>
> On Tue, Jun 15, 2021, 20:19 Benjamin Marwell <bm...@apache.org> wrote:
>
>> Tamás,
>>
>> which module do you open?
>>
>> In most cases I have encountered, adding jaxb as a dependency to the
>> project is sufficient. But to be sure, we would need to see an example.
>>
>> I think this would have long been noticed if it was a common problem.
>>
>> Ben
>>
>>
>> On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, <ta...@cservenak.net> wrote:
>>
>> > Howdy,
>> >
>> > Robert, I think you are wrong:
>> >
>> > from Java 11 migration guide
>> >
>> > --add-opens
>> > If you have to allow code on the class path to do deep reflection to
>> access
>> > nonpublic members, then use the --add-opens runtime option.
>> > Some libraries do deep reflection, meaning setAccessible(true), so they
>> can
>> > access all members, including private ones. You can grant this access
>> using
>> > the --add-opens option on the java command line. No warning messages are
>> > generated as a result of using this option.
>> >
>> > Hence, it is needed even for CP applications, that do require "deep
>> > reflection".
>> >
>> > HTH
>> > Tamas
>> >
>> > On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <rf...@apache.org>
>> > wrote:
>> >
>> > > 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.
>> > >
>> > > thanks,
>> > > Robert
>> > > On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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
>> > >
>> >
>>
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Tamás Cservenák <ta...@cservenak.net>.
Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what it
needs to be opened up.
T on phone
On Tue, Jun 15, 2021, 20:19 Benjamin Marwell <bm...@apache.org> wrote:
> Tamás,
>
> which module do you open?
>
> In most cases I have encountered, adding jaxb as a dependency to the
> project is sufficient. But to be sure, we would need to see an example.
>
> I think this would have long been noticed if it was a common problem.
>
> Ben
>
>
> On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, <ta...@cservenak.net> wrote:
>
> > Howdy,
> >
> > Robert, I think you are wrong:
> >
> > from Java 11 migration guide
> >
> > --add-opens
> > If you have to allow code on the class path to do deep reflection to
> access
> > nonpublic members, then use the --add-opens runtime option.
> > Some libraries do deep reflection, meaning setAccessible(true), so they
> can
> > access all members, including private ones. You can grant this access
> using
> > the --add-opens option on the java command line. No warning messages are
> > generated as a result of using this option.
> >
> > Hence, it is needed even for CP applications, that do require "deep
> > reflection".
> >
> > HTH
> > Tamas
> >
> > On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <rf...@apache.org>
> > wrote:
> >
> > > 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.
> > >
> > > thanks,
> > > Robert
> > > On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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
> > >
> >
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Benjamin Marwell <bm...@apache.org>.
Tamás,
which module do you open?
In most cases I have encountered, adding jaxb as a dependency to the
project is sufficient. But to be sure, we would need to see an example.
I think this would have long been noticed if it was a common problem.
Ben
On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, <ta...@cservenak.net> wrote:
> Howdy,
>
> Robert, I think you are wrong:
>
> from Java 11 migration guide
>
> --add-opens
> If you have to allow code on the class path to do deep reflection to access
> nonpublic members, then use the --add-opens runtime option.
> Some libraries do deep reflection, meaning setAccessible(true), so they can
> access all members, including private ones. You can grant this access using
> the --add-opens option on the java command line. No warning messages are
> generated as a result of using this option.
>
> Hence, it is needed even for CP applications, that do require "deep
> reflection".
>
> HTH
> Tamas
>
> On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <rf...@apache.org>
> wrote:
>
> > 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.
> >
> > thanks,
> > Robert
> > On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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
> >
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
Robert, I think you are wrong:
from Java 11 migration guide
--add-opens
If you have to allow code on the class path to do deep reflection to access
nonpublic members, then use the --add-opens runtime option.
Some libraries do deep reflection, meaning setAccessible(true), so they can
access all members, including private ones. You can grant this access using
the --add-opens option on the java command line. No warning messages are
generated as a result of using this option.
Hence, it is needed even for CP applications, that do require "deep
reflection".
HTH
Tamas
On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <rf...@apache.org> wrote:
> 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.
>
> thanks,
> Robert
> On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Tibor Digaňa <ti...@googlemail.com.INVALID>.
The example given by Guillaume looks interesting.
jre-options =
${jre-${java.specification.version}-options:-${jre-default-options}}
jre-default-options = [default options]
jre-1.8 = [my JDK 1.8 specific options]
But I would maybe distinguish between:
1. Maven options
2. and plugin options
And to be more specific, the first case (1) may have more alternatives with
[root]/.mvn/jvm.config.
Example:
1. [root]/.mvn/jvm9.config
2. [root]/.mvn/jvm11.config
3. [root]/.mvn/jvm16.config
It does not make sense to have "--add-opens" and similar things in the
jvm.config for plugins (2) because the lifecycle and plugins are complex.
We should not end up with a kind of config structure in the jvm.config. Due
to this we have POM structure.
Perhaps the POM should have new non/transitive entry points dedicated for
the phases of the build life cycle rather than parameters (entry points) in
the plugins.
I believe the users would be lucky if e.g. JUnit5 BOM (one for compile,
runtime, another for test and test-compile) would have these entry points
(as a recommendation from the OSS groups) and the user would just use it
without writing "--add-reads ... --add-exports ... --add-opens ...
--add-modules ... etc.".
Cheers
Tibor
On Wed, Jun 16, 2021 at 2:27 PM Guillaume Nodet <gn...@apache.org> wrote:
> Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet <gn...@apache.org> a
> écrit
> > :
> >
> > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > a
> > > écrit :
> > >
> > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gn...@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.
> > > >
> > > > Maybe I'm the only one, but when I see a project with a pom.xml and I
> > > just
> > > want to build it, the first thing I try is `mvn install -DskipTests`.
> > This
> > > work in most of the case, and I think it should stay that way. That's
> why
> > > I'm looking for a way to configure those options per-project.
> > >
> > > So yes, that's right, MAVEN_OPTS may solve the problem. But that does
> > not
> > > solve my problem which is:
> > > * how to set up the environment (maven options or jvm options or
> > > eventually environment variable)
> > > * with a config per project (not at the maven installation level)
> > > * with something that can have a bit of logic so that it can depend
> on
> > > which jdk version is used
> > >
> >
> > setenv.sh in multimoduleroot/.mvn ;)
> >
> >
> Actually, thinking about it, this also raises a few problems. It makes the
> life for tools embedding maven much more complicated.
> I'm wondering if a configuration based solution wouldn't be easier to work
> with (i.e. without having to interpret or spawn a command shell) ?
>
> In felix / karaf, the problem was solved by using property files and
> property substitution. This could look like:
> jre-options =
> ${jre-${java.specification.version}-options:-${jre-default-options}}
> jre-default-options = [default options]
> jre-1.8 = [my JDK 1.8 specific options]
>
> This kind of configuration allows you to lay out a bit of logic in the
> configuration.
> This is just an example of course, but it would be more inlined with the
> [root]/.mvn/jvm.config and like.
>
> Guillaume
>
>
> > >
> > >
> > >
> > > >
> > > > >
> > > > > 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.
> > > >
> > >
> > > See above, I'm not looking for maven to fix the problem. I'm looking
> for
> > > maven to provide a way to fix the problem. Which implies, the exact
> > option
> > > to configure is up to the user, so the fact that is already deprecated
> is
> > > irrelevant.
> > >
> > > >
> > > >
> > > > >
> > > > > 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
> > > >
> > > >
> > > So could we enhance the maven shell script to look for a
> > > [project-root]/.mvn/setenv.sh and call it ? That would definitely
> solve
> > > the problem.
> > >
> >
> > +1
> >
> >
> > >
> > >
> > > >
> > > > >
> > > > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gnodet@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 <
> > > > > rmannibucau@gmail.com>
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <
> > gnodet@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 <
> > > > rfscholte@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 <
> gnodet@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
> > > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
--
Cheers
Tibor
Re: Supporting building with incompatible JDK versions on a single project
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 16 juin 2021 à 14:27, Guillaume Nodet <gn...@apache.org> a écrit :
> Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet <gn...@apache.org> a
> écrit
> > :
> >
> > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > a
> > > écrit :
> > >
> > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gn...@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.
> > > >
> > > > Maybe I'm the only one, but when I see a project with a pom.xml and I
> > > just
> > > want to build it, the first thing I try is `mvn install -DskipTests`.
> > This
> > > work in most of the case, and I think it should stay that way. That's
> why
> > > I'm looking for a way to configure those options per-project.
> > >
> > > So yes, that's right, MAVEN_OPTS may solve the problem. But that does
> > not
> > > solve my problem which is:
> > > * how to set up the environment (maven options or jvm options or
> > > eventually environment variable)
> > > * with a config per project (not at the maven installation level)
> > > * with something that can have a bit of logic so that it can depend
> on
> > > which jdk version is used
> > >
> >
> > setenv.sh in multimoduleroot/.mvn ;)
> >
> >
> Actually, thinking about it, this also raises a few problems. It makes the
> life for tools embedding maven much more complicated.
> I'm wondering if a configuration based solution wouldn't be easier to work
> with (i.e. without having to interpret or spawn a command shell) ?
>
> In felix / karaf, the problem was solved by using property files and
> property substitution. This could look like:
> jre-options =
> ${jre-${java.specification.version}-options:-${jre-default-options}}
> jre-default-options = [default options]
> jre-1.8 = [my JDK 1.8 specific options]
>
> This kind of configuration allows you to lay out a bit of logic in the
> configuration.
> This is just an example of course, but it would be more inlined with the
> [root]/.mvn/jvm.config and like.
>
Thing is that we can't handle this file cleanly (as seen in the system
property thread) so maven would be broken.
Now i'm not very worried about embedded tools, it is trivial to execute the
script and get MAVEN_OPTS set properly for most tools (thinking to the
mainstream IDE and mvnd to explicit what I have in mind).
Worse case it is not different than today where a few of IDE just ignores
it without making too much issue in user land AFAIK so let's say it is just
more limiting than helping for most cases since it would be way more work
to setup properly than just forcing some options which is known by anyone
IMHO.
>
> Guillaume
>
>
> > >
> > >
> > >
> > > >
> > > > >
> > > > > 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.
> > > >
> > >
> > > See above, I'm not looking for maven to fix the problem. I'm looking
> for
> > > maven to provide a way to fix the problem. Which implies, the exact
> > option
> > > to configure is up to the user, so the fact that is already deprecated
> is
> > > irrelevant.
> > >
> > > >
> > > >
> > > > >
> > > > > 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
> > > >
> > > >
> > > So could we enhance the maven shell script to look for a
> > > [project-root]/.mvn/setenv.sh and call it ? That would definitely
> solve
> > > the problem.
> > >
> >
> > +1
> >
> >
> > >
> > >
> > > >
> > > > >
> > > > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gnodet@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 <
> > > > > rmannibucau@gmail.com>
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <
> > gnodet@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 <
> > > > rfscholte@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 <
> gnodet@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
> > > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Le mer. 16 juin 2021 à 13:53, Guillaume Nodet <gn...@apache.org> a écrit
> :
>
> > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <rm...@gmail.com>
> a
> > écrit :
> >
> > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gn...@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.
> > >
> > > Maybe I'm the only one, but when I see a project with a pom.xml and I
> > just
> > want to build it, the first thing I try is `mvn install -DskipTests`.
> This
> > work in most of the case, and I think it should stay that way. That's why
> > I'm looking for a way to configure those options per-project.
> >
> > So yes, that's right, MAVEN_OPTS may solve the problem. But that does
> not
> > solve my problem which is:
> > * how to set up the environment (maven options or jvm options or
> > eventually environment variable)
> > * with a config per project (not at the maven installation level)
> > * with something that can have a bit of logic so that it can depend on
> > which jdk version is used
> >
>
> setenv.sh in multimoduleroot/.mvn ;)
>
>
Actually, thinking about it, this also raises a few problems. It makes the
life for tools embedding maven much more complicated.
I'm wondering if a configuration based solution wouldn't be easier to work
with (i.e. without having to interpret or spawn a command shell) ?
In felix / karaf, the problem was solved by using property files and
property substitution. This could look like:
jre-options =
${jre-${java.specification.version}-options:-${jre-default-options}}
jre-default-options = [default options]
jre-1.8 = [my JDK 1.8 specific options]
This kind of configuration allows you to lay out a bit of logic in the
configuration.
This is just an example of course, but it would be more inlined with the
[root]/.mvn/jvm.config and like.
Guillaume
> >
> >
> >
> > >
> > > >
> > > > 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.
> > >
> >
> > See above, I'm not looking for maven to fix the problem. I'm looking for
> > maven to provide a way to fix the problem. Which implies, the exact
> option
> > to configure is up to the user, so the fact that is already deprecated is
> > irrelevant.
> >
> > >
> > >
> > > >
> > > > 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
> > >
> > >
> > So could we enhance the maven shell script to look for a
> > [project-root]/.mvn/setenv.sh and call it ? That would definitely solve
> > the problem.
> >
>
> +1
>
>
> >
> >
> > >
> > > >
> > > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gn...@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 <
> > > > rmannibucau@gmail.com>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <
> gnodet@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 <
> > > rfscholte@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 <gn...@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
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
------------------------
Guillaume Nodet
Re: Supporting building with incompatible JDK versions on a single project
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 16 juin 2021 à 13:53, Guillaume Nodet <gn...@apache.org> a écrit :
> Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <rm...@gmail.com> a
> écrit :
>
> > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gn...@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.
> >
> > Maybe I'm the only one, but when I see a project with a pom.xml and I
> just
> want to build it, the first thing I try is `mvn install -DskipTests`. This
> work in most of the case, and I think it should stay that way. That's why
> I'm looking for a way to configure those options per-project.
>
> So yes, that's right, MAVEN_OPTS may solve the problem. But that does not
> solve my problem which is:
> * how to set up the environment (maven options or jvm options or
> eventually environment variable)
> * with a config per project (not at the maven installation level)
> * with something that can have a bit of logic so that it can depend on
> which jdk version is used
>
setenv.sh in multimoduleroot/.mvn ;)
>
>
>
> >
> > >
> > > 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.
> >
>
> See above, I'm not looking for maven to fix the problem. I'm looking for
> maven to provide a way to fix the problem. Which implies, the exact option
> to configure is up to the user, so the fact that is already deprecated is
> irrelevant.
>
> >
> >
> > >
> > > 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
> >
> >
> So could we enhance the maven shell script to look for a
> [project-root]/.mvn/setenv.sh and call it ? That would definitely solve
> the problem.
>
+1
>
>
> >
> > >
> > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > a
> > > écrit :
> > >
> > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gn...@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 <
> > > rmannibucau@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gnodet@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 <
> > rfscholte@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 <gn...@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
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gn...@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.
>
> Maybe I'm the only one, but when I see a project with a pom.xml and I just
want to build it, the first thing I try is `mvn install -DskipTests`. This
work in most of the case, and I think it should stay that way. That's why
I'm looking for a way to configure those options per-project.
So yes, that's right, MAVEN_OPTS may solve the problem. But that does not
solve my problem which is:
* how to set up the environment (maven options or jvm options or
eventually environment variable)
* with a config per project (not at the maven installation level)
* with something that can have a bit of logic so that it can depend on
which jdk version is used
>
> >
> > 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.
>
See above, I'm not looking for maven to fix the problem. I'm looking for
maven to provide a way to fix the problem. Which implies, the exact option
to configure is up to the user, so the fact that is already deprecated is
irrelevant.
>
>
> >
> > 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
>
>
So could we enhance the maven shell script to look for a
[project-root]/.mvn/setenv.sh and call it ? That would definitely solve
the problem.
>
> >
> > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau <rm...@gmail.com>
> a
> > écrit :
> >
> > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gn...@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 <
> > rmannibucau@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gn...@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 <
> rfscholte@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 <gn...@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
> >
>
--
------------------------
Guillaume Nodet
Re: Supporting building with incompatible JDK versions on a single project
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 16 juin 2021 à 12:05, Guillaume Nodet <gn...@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 <rm...@gmail.com> a
> écrit :
>
> > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gn...@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 <
> rmannibucau@gmail.com>
> > a
> > > écrit :
> > >
> > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gn...@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 <rfscholte@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 <gn...@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
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Guillaume Nodet <gn...@apache.org>.
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 <rm...@gmail.com> a
écrit :
> Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gn...@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 <rm...@gmail.com>
> a
> > écrit :
> >
> > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gn...@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 <rf...@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 <gn...@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
Re: Supporting building with incompatible JDK versions on a single project
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 16 juin 2021 à 08:39, Guillaume Nodet <gn...@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 <rm...@gmail.com> a
> écrit :
>
> > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gn...@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 <rf...@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 <gn...@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
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Guillaume Nodet <gn...@apache.org>.
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 <rm...@gmail.com> a
écrit :
> Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gn...@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 <rf...@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 <gn...@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
Re: Supporting building with incompatible JDK versions on a single project
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mar. 15 juin 2021 à 23:39, Guillaume Nodet <gn...@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 <rf...@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 <gn...@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
>
Re: Supporting building with incompatible JDK versions on a single project
Posted by Guillaume Nodet <gn...@apache.org>.
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.
Le mar. 15 juin 2021 à 19:04, Robert Scholte <rf...@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 <gn...@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
Re: Supporting building with incompatible JDK versions on a single
project
Posted by Robert Scholte <rf...@apache.org>.
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.
thanks,
Robert
On 15-6-2021 18:43:35, Guillaume Nodet <gn...@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