Hi,
Le mar. 12 sept. 2023 à 09:16, Henning Schmiedehausen < henn...@schmiedehausen.org> a écrit : > I am not sure that we have to. I think that the discussion got derailed by > disagreement about the "automatic module name" entry in a jar. > > My interpretation of JEPS-261 is, that there are only two things: > > - JPMS modules, which have a module-info.class file at the root of the > implementation jar > - everything else, which are treated as "automatic modules". The entry in > the manifest controls the "automatically created name" for the module. But > they are fundamentally the same thing. > > So for running the build lifecycle, there is IMHO only: > > - if there is a module-info.java in any source root present, it is a JPMS > module. This should use the JPMS toolchain > This is an assumption and regularly not true, in particular when the build is not intended to use JPMS at runtime, the module should stick to classpath. > - Everything else gets treated like a "legacy" java build, independent of > whether there is an automatic module name set in the jar or not or what JDK > version is used to build the artifact > > Maven spends a lot of time trying to deal with corner cases and I am not > sure that we get them right. > AFAIK mainstream frameworks (spring, microprofile, jakarta) ignore by default JPMS (and most of their env do not even read module-info) so guess it stays the default today. > > -h > > > > > > On Sun, Sep 3, 2023 at 1:58 AM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2023-09-02 à 21 h 15, Henning Schmiedehausen a écrit : > > > > > This is the piece that really makes me sad. We tend to get lost in > > > "rightness" discussions and don't show pragmatism. > > In this case we have an opinion-free, objective criterion: make possible > > to pass to Java tools (java, javac, javadoc…) command-line arguments > > that work for a JPMS application. Making that task easier would be a > > bonus, but at first at least make it possible. > > > > > > >> 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. > > Recent emails about Maven 4 made me think that POM changes may be > > possible. But anyway, no matter if POM changes are accepted or not, > > there is also a need for some global option for controlling the current > > algorithm. The reason is that even if POM changes were accepted, the > > current algorithm would still be the default applied when nothing is > > specified in the POM, and that default needs to be changed. > > > > Martin > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
