Just as a reminder: * type=module breaks downstream consumers not upgrading maven * transitivity is broken since everything ends in modulepath whereas in most cases you want it in the classpath
So really we should move forward on something else than artifact definition as the sole solution if we want to support jpms as a first citizen (once again no issue for me to not do, my current main issue is to introduce something making builds more complex and not solving end users issue). 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 jeu. 2 nov. 2023 à 13:25, Tamás Cservenák <ta...@cservenak.net> a écrit : > Just to chime in to Martin thoughts: > > - yes, the default "type" is still "jar" (so if you omit type, "jar" is > applied as today) > - transitivity: yes, as I show above, project-impl [type=module] depends on > project-api [type=module] so the whole tree lands on "modulepath". > - override: exactly as Martin says, if you want to override and have > project-api on classpath, just override it > - I wanted to expand the "status" plugin to show more info, but hit some > issues with mvn4 API current state, so I am looking into that first... > > On Thu, Nov 2, 2023 at 1:20 PM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2023-11-02 à 12 h 53, Romain Manni-Bucau a écrit : > > > > > You would also note that using "type" *forces* users to care about > > > this separation too in an unexpected way. > > > > > Type is an optional element. The use of <type>module</type> is a > > workaround for the heuristic rules sometime doing the wrong choice. But > > <type> could continue to be optional if users have control over those > > rules (that would be a separated thread), with <type> used only when > > fine-grained control is desired. > > > > > > > I import helidon (which is fully jpms friendly) so I get > > > helidon-server on the module-path but helidon-common on the classpath? > > > (indeed keep in mind if you fix this you will get the opposite case > > > blowing up). > > > > > Whether to put helidon-common on module-path would be determined by the > > <dependency> declaration in the helidon.pom file. That file already > > needs to be read anyway for finding the helidon-common transitive > > dependency. Users can override if desired by adding their own > > <dependency> declaration in their project, in the same way as we can > > override dependency versions today. > > > > > > > Also keep in mind the pom modification is *not* an option as commented > > > and would mean the consumer depends on the consumed artifact which, we > > > saw it, is not the case at all with java modules > > > > > I do not understand this part. Consumer already depends on consumed > > artifact, since it determines transitive dependencies. The use of JPMS > > changes nothing here. > > > > > > > 90% will want modules on classpath > > > > > I think it is more "90% does not care as long as it works". If a library > > has been designed in such a way that it needs to be on the module path > > for working properly, I think that most users would be happy to let > > Maven do the right thing according the metadata found in POM files, and > > be explicit with <type> only if they need to. > > > > > > > So at the end we are exactly in the current (doing no change at all) > > > situation where you need to tune all your stack to be stable, reliable > > > and properly handled. > > > > > No, the current situation is that we cannot tune the classpath and > > module-path. There is no way I could see to override the decision taken > > by the current heuristic rules. > > > > Martin > > > > >
