Le jeu. 2 nov. 2023 à 17:24, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Romain, > > Could you draft an example project that proves or at least showcases your > points? > It's probably me, but I don't get your responses :( > > WTH is "lifecycle of your project graph"? > > But really, could you draft an example project that showcases your points? > Just the one I mentionned earlier: 1. create three projects: lib and app 2. write lib as a module reactor (ensure it has some transitive dep, maybe lib-common with type=module too) and app as maven projects are today (all is jar) - indeed app consumes lib as a module so it has a module-info which references lib module-info meta like SPI and packages 3. make lib move to your proposal and moving from 1.0.0 to 1.0.1 (no real code change), check app has no change in terms of dispatching to module path/classpath Now, do the same example but with app in a classpath centric build (spring boot, EE, ...) which consumes lib1 as a classpath jar even if it is a module in its original pom (perfectly valid). You can make one of both cases working but not both with your proposal. Indeed last one will be broken even if it is the most common one (so we break maven philosophy - and user interaction IMHO). By design there is no way to make it work smoothly at artifact level. We can, indeed, do yet another guess algorithm which would be so clever than we would start again this thread in a few months but as mentionned we have all we need to make it work today and setup is not that huge but requires dependency plugin. You want all the classpath on module path? dump the classpath with dependency plugin in a maven property and forward it to module path in the 3-4 plugins, be it. Until JPMS reach 40% of projects I guess we should be able to leave with it and it avoids to introduce any new concept or mess up what type is for end users (even if you are technically 100% right, type stays the extensions for users and it is easier to make it aligned most of the time for us than putting unread doc everywhere IMHO). Hope it helps. > > T > > On Thu, Nov 2, 2023 at 2:08 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Le jeu. 2 nov. 2023 à 13:59, Tamás Cservenák <ta...@cservenak.net> a > > écrit : > > > > > Howdy, > > > > > > "not upgrading maven" can simply be extrapolated to "not upgrading > java", > > > so what are we talking about at all here? Imposing illogical > requirements > > > really does not make sense. > > > > > > (today) I'm writing app A, and I'm depending on helidon. I'm using java > 17 > > and maven 3.9 (last stables when project was setup). > > > > Tomorrow helidon switched to type=module cause it fits better their > build. > > > > I'm expecting my app A to still work at helidon new release, just edit > > <helidon.version> and be it....but boom, it just breaks cause module is > an > > unknown type without a handler. > > > > > > > The whole point of mvn4 is to allow progress at > > > the same time not excluding the mvn3 universe (consumer POM). > > > > > > > Progress on the *build*, not much on consuming side cause it can only > work > > for a version then and we are doomed. > > > > > > > "transitivity is broken" again, it ends where you declare it as > explained > > > above, so am really unsure where we miss each other. > > > > > > > No no, think lifecycle of your project graph, this becomes insane to do > > that at that level in real life so really hope we avoid it. > > > > > > > > > > Could you draft an example project that proves your points? > > > > > > Thanks > > > T > > > > > > On Thu, Nov 2, 2023 at 1:52 PM Romain Manni-Bucau < > rmannibu...@gmail.com > > > > > > wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > >
