Hi Eric, point is that we can't deprecate 3.3 too IMHO. 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. 16 avr. 2020 à 11:18, Eric Lilja <mindcoo...@gmail.com> a écrit : > But the proposal was not to deprecate 3.5, but anything below (since 3.5 > was when the resolver was introduced)? > > - Eric L > > On Thu, Apr 16, 2020 at 11:08 AM Romain Manni-Bucau <rmannibu...@gmail.com > > > wrote: > > > Hi Tibor, technically you are likely right but deprecating is not only > > technical, i'd say it is only 10% of the choice (even if it is what > > triggers the discussion). > > The biggest part for me is how it affects users. > > 3.5.x is only 3 years old so I think it is too early to deprecate it > (guess > > we should target at least 5 years of support) so I think 3.3 can't be > > deprecated today but maybe in 1 or 2 years. > > That said we can stop supporting 3.3 for new version of plugins and only > be > > reactive to backport a fix if needed (it is quite rare I think). This way > > we can move forward and not send a negative message for enterprises. > > In other words: we support >= 3.3 but plugin upgrades can target only > > > 3.5. > > > > Wdyt? > > > > 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. 16 avr. 2020 à 10:41, Tibor Digana <tibordig...@apache.org> a > > écrit : > > > > > The Eclipse Aether looks like a strong argument. > > > If any user would open an issue to provide a fix on the top of Eclipse > > > Aether then we say 'no' already today in 3.7.0. > > > So the user has to switch to 3.5.0+ which would end up for him as the > > > same as deprecating 3.0.x - 3.3.x. > > > I know that it is a big extend, i understand that but this is > > > currently the outcome of my analysis. > > > > > > I don't know what you think about this view. > > > > > > On Thu, Apr 16, 2020 at 8:52 AM Hervé BOUTEMY <herve.bout...@free.fr> > > > wrote: > > > > > > > > +1 to deprecate 3.0.x > > > > > > > > TLDR; no need to deprecate Eclipse Aether, which would mean > deprecating > > > also > > > > 3.1.x, 3.2.x and 3.3.x > > > > > > > > details: > > > > "deprecate everything before the maven-resolver import" would mean > > > deprecating > > > > up to 3.3.x [1] > > > > > > > > Given that maven-resolver has exactly the same API as Eclipse Aether > > (in > > > > org.eclipse.aether java package) but just a change in Maven > coordinates > > > (that > > > > are all filtered by Maven core class loading, then not really an > > issue), > > > I'm > > > > not convinced this is absolutely necessary to go to that extend > > > > > > > > what is really useful is to deprecate anything that is not in > > > > org.eclipse.aether Java package, because it is a nightmare in terms > of > > > Java > > > > code compatibility: this means deprecating 3.0.x only [2], given the > > > switch to > > > > Eclipse Aether has been done in 3.1.0 [3] > > > > And, for the record, the switch to Maven Artifact Resolver has been > > done > > > in > > > > 3.5.0 [4] > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > [1] https://maven.apache.org/ref/3.3.9/dependency-management.html > > > > > > > > [2] https://maven.apache.org/ref/3.0.5/dependency-management.html > > > > > > > > [3] https://maven.apache.org/ref/3.1.0/dependency-management.html > > > > > > > > [4] > > > https://maven.apache.org/ref/3.5.0-alpha-1/dependency-management.html > > > > > > > > Le jeudi 16 avril 2020, 00:22:20 CEST Manfred Moser a écrit : > > > > > +100 > > > > > > > > > > I would deprecate everything before the maven-resolver import back > to > > > the > > > > > project while you are at it. Not sure exact version but 3.1x would > > > > > definitely on that list as well. Maybe also 3.2x > > > > > > > > > > Manfred > > > > > > > > > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00): > > > > > > Some users still use Maven 3.0.5 and they require a support for > > > > > > compatibility reasons between nowadays Maven plugins and the > Maven > > > > > > 3.0.x. > > > > > > > > > > > > We have a couple of reasons to deprecate this version (JSR-330, > > > > > > Components injection, Logger) and we have discussed this issue in > > > > > > https://github.com/apache/maven-surefire/pull/274 > > > > > > > > > > > > Let's discuss it. > > > > > > > > > > > > Cheers > > > > > > Tibor17 > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > -- > > > Cheers > > > Tibor > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
