Last week, I communicated my thoughts on why POM model 4.1.0 should not be introduced in the 3.x series. I said that I believed that forcing two separate lines of development would best be beneficial to the overall code base (which is big!!!). The benefit, so I think, is that 3.x would focus on graceful handling of new metadata; the 4.x line would be free to develop new features. The two concerns are important enough that one code base shouldn't try to handle both -- especially if there is desire to backport graceful handling into even older releases as small point releases.
I am not sure there was any direct responses so I am raising the issue again. Does anyone find this appealing? And if not, why not? This is the direction I am advocating, but unless there is any traction on it, I don't want to beat the drum on a dead idea. Thanks everyone. Cheers, Paul On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <[email protected]> wrote: > Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY: > > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit : > >> Am 08/24/16 um 00:40 schrieb Christian Schulte: > >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY: > >>>> yes, people providing libraries have this big choice to do: when to > >>>> upgrade > >>>> minimum JRE version for consumers. > >>>> > >>>> yes, we can add them another new big decision to take: when to upgrade > >>>> minium Maven version to consume the library? > >>> > >>> When that upgrade lets them solve issues they cannot solve in another > way. > >> > >> No issue with what 4.0.0 provides -> no need to upgrade (do not upgrade) > >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that provides > >> the solution. > >> > >> Regards, > > my point is that a library producer creates a Maven requirement for a > library > > consumer. > > > > I'll say it crude for us: Maven is the only tool that give library > consumers > > such issues. People using other build tools don't have this issue when > using > > central. > > Can you provide some links to source code of some other build tool which > does the whole dependency resolution including import scope processing > itself without re-using any Maven component? Have others really > implemented the dependency resolution with exactly the same behaviour > Maven has? For a build tool running on the Java VM, they would have > re-used the 'maven-model-builder' or 'maven-aether-provider', I guess. > That means they would just need to upgrade to 'maven-aether-provider' > 3.4 and be done with it. > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
