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