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

Reply via email to