Robert, you might missed this quite long thread that happened about a year ago: https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn
Just to get into the picture, and not repeat the whole story again :) Thanks T On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte <rfscho...@apache.org> wrote: > > Inline responses... > > -----Original Message----- > From: Martin Desruisseaux <martin.desruisse...@geomatys.com> > Sent: donderdag 24 oktober 2024 12:38 > To: dev@maven.apache.org > Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin > beta-2 > > Le 2024-10-24 à 12 h 07, Robert Scholte a écrit : > > > > Can you explain the problem you're trying to solve? In particular I > > don't understand the need for modular-jar and classpath-jar, as > > currently both classpath and modulepath are already build up correctly > > based on the module descriptors. > > > The problem is that they are not always build up correctly. Maven uses > heuristic rules, and there is currently no easy way a user could change > Maven's mind when those rules do not match user's intend. Examples: > > * A user may want to put non-modular JAR files on the module path. > This is called automatic modules. I'm aware that there are arguments > about whether this is good practice or not, but the new compiler > plugin is not taking position in that debate. Automatic modules are > officially supported and part of the Java specification, and there > are sometime legitimate reasons to want to use them. > > >> What is effectively the difference here? As long as there's no reference > >> from a module descriptor to a module (either named or automatic) there > >> should be no difference. > >> It is already possible to refer to automatic modules, including a big > >> disclaimer in case it is a library (automatic modules are less problematic > >> for applications) > >> Do you have a minimized project that demonstrates that there are different > >> results? > > * Maven currently puts everything on the class-path when a project is > non-modular. But a non-modular project may still want to put its > modular dependencies on the module-path. This choice changes the way > that services are loaded for example. > > >> Loading services sounds like a runtime issue, not a compile time issue. > >> Do you have a minimized project that demonstrates that there are different > >> results? > > So what Maven is currently doing is not always the right thing to do. It may > be a reasonable default however. Therefore, the "jar" type will continue to > behave as today. But the "classpath-jar" and "modular-jar" > types, or something equivalent, are needed when the Maven's heuristic rules > don't do what the user wants. > > >> I think that the type is abused here. Also, does this mean that other > >> tools suddenly need to understand this type as well? Or does Maven4 revert > >> it back to "jar" in the consumer-pom, in which case you will have > >> different behavior at runtime? > >> In both cases there's an issue. > >> If there really is an issue, there should be a solution that doesn't > >> impact any other pom-consumer, it should be scoped to maven-build section. > > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
