Thanks, that's indeed long. But seeing the result makes we wonder if the right decision has been made with regard to pom consumption. To me this looks like this is going to disrupt the java ecosystem. Just one question: what will happen with Maven3 users (or any other tool) if one of their dependencies has this special type? Not sure why this had to be forced into the current modelVersion 4.0.0 like this.
Anyway, I guess the decision has been made. Robert -----Original Message----- From: Tamás Cservenák <ta...@cservenak.net> Sent: donderdag 24 oktober 2024 14:01 To: Maven Developers List <dev@maven.apache.org> Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
