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 > >