Hi,

The thing is you can't rely on the pom to know if you use a JPMS or not
module cause most libs will not fill that and even if, then you never know
if consumer wants that.
So you are stucked by design on being explicit on 200 entries paths with
pom updates or not.

So only way to build right is to explicitly set the list of jpms modules
which ultimately means disabling all implicit plugins and use maven (java)
tool plugin or exec plugin to set the command lines yourself with the right
classpath/modulepath.

A good alternative is a maven extension which visits the maven module
module-info to extract the requirements then browse the dependencies to do
the same and deduce both values and inject them in compiler, surefire, ...
plugins. It could get some pom properties config for the tuning when needed
(mainly excludedJpmsModule names only).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 2 sept. 2023 à 23:16, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :

> On Sat, Sep 2, 2023 at 2:57 AM Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Hello Henning
> >
> > That migration would have been impossible with Maven, so we had to
> > switch to Gradle. Even then it was difficult, but it could be made much
> > easier with more adequate tooling support. Discussions with Gradle
> > developers about possible improvements started on GitGub issues. On
> > Maven side we could improve things with small steps.
>
>
> This is the piece that really makes me sad. We tend to get lost in
> "rightness" discussions and don't show pragmatism.
>
>
> > The most urgent one
> > in my opinion is to give control to developers about class-path versus
> > module-path decisions.
> >
>
> I tend to agree with this, however extending the pom model is most likely
> not a viable option.
>
> -h
>

Reply via email to