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 wrote:
> Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau a
> écrit :
>
> > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet a
> écrit
> > :
> >
> > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > a
> > > écrit :
> > >
> > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet 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
