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