I have 2 remarks to add: 1. even if a plugin has a dependency on an old Maven core artifact, it's at compile time but not runtime: the artifact used at runtime is the artifact from the actual Maven version used, the old artifact isn't even downloaded. Then there is really no problem with plugins using old Maven core artifacts during their compilation
2. even given greatest efforts done, not everything works perfectly with Maven 3: maven-dependency-plugin:tree and maven-project-info-reports- plugin:dependencies used to give sometimes wrong information with Maven 3 until their 2.5 release, which only happened at the beginning of this month (yes, less than one month). AFAIK, these were the last known compatibility problems with Maven 3 by core plugins at Apache. I suppose there are still such problems for some (rare) plugins outside. And users still report some regressions with Maven 3 in advanced situations: once again, they are very rare since there was a huge work to avoid them, but nobody is perfect. Definitely, Maven 3 is the way to go for anybody starting a project today, but we cannot simply drop 2.2.1 today and leave most advanced users with remaining problems: if they cannot upgrade, believe me, that's not because they don't want to or are unable to do the job but because there are still little but very hard to find and fix bugs in Maven 3 or some plugins Regards, Hervé Le vendredi 17 août 2012 12:32:54 Stephen Connolly a écrit : > On 17 August 2012 11:33, Stanislav Ochotnicky <sochotni...@redhat.com>wrote: > > Quoting Jason van Zyl (2012-07-30 17:43:13) > > > > > On Jul 30, 2012, at 10:10 AM, Stephen Connolly wrote: > > > > The only reason to do this from my PoV is if the plugin requires > > > > features > > > > > > only available in Maven 3. > > > > > > > > There are still a significant number of users who use Maven 2.2.1, > > > > yeah I > > > > > > would love to get them to jump up to 3.0.4, but I acknowledge that is > > > > something that may be beyond their control. Forcing plugin > > > > dependencies up > > > > > > without a valid driving requirement is just forcing unnecessary pain > > > > on the > > > > > > end users. > > > > > > > > IMHO features should drive the upgrading of dependencies, nothing > > > > else. > > > > > > +1 > > > > > > There is little value in updating plugins to use Maven 3.x components > > > > for the sake of it. The reason we spent so much time making sure that 3.x > > runs older components was to ensure no one has to do this. > > > > Apparently sending out inquiries before leaving for 2 week vacation was > > not ideal :-) > > > > So my view was somewhat different. I would hope you would like to get > > rid of direct dependencies on old Maven 2.x code. And as you've said > > Maven 3.x runs older components just fine, so this wouldn't have to be > > "Let's switch tomorrow". Instead it could be a gradual maintenance > > cleanup. Removing dead and/or unmaintained code. But I understand > > people using Maven 2.2.1 would be unable to upgrade their dependencies > > to new versions using Maven 3.x artifacts (or at least it's not a > > supportable use-case even though it might work). > > Upgrading dependencies just to force people to upgrade Maven will leave a > bad taste in user's mouths. > > Again, it is *features* that will and must drive the upgrading of > dependencies. > > Where I have a new *feature* that mandates using newer dependencies, then > users wanting that feature will have to upgrade to use the new feature. > > A case in point is some of the experiments I have been working on with > regard to handling dynamic changes in a multi-module reactor while running > a webapp (like jetty:run or tomcat:run) from that reactor to allow for live > development: jszip.org > > I started off using only Maven 2.2.1 dependencies (because I was requiring > Java 1.5 and Maven 2.2.1 is the first recommended version of Maven that > mandates Java 1.5+ [2.1.0 and 2.2.0 have critical bugs in signing artifacts > for deployment to remote repos and other issues, hence not recommended, and > 2.0.11 runs with Java 1.4]) > However, I reached a point where, to handle some of the types of model > restructuring that takes place when you allow people to edit the pom, I was > forced to up the dependencies to Maven 3.0 > > When I get jszip-maven-plugin to "feature complete" I suspect/hope that it > will be sufficiently compelling that anyone doing webapp development with > Maven will *just have to use it* and hence the features it adds will compel > people to upgrade to Maven 3.0.4+ > > A dependency version should be the lowest version that provides > compatibility with the latest code and exposes the features you require. > > If in 50 years time that means that there is still some Maven plugins that > depend on some of the published Maven APIs from Maven 2.0 then that is a > success on behalf of the Maven developers, not a failure to force people to > upgrade. > > > In any case, you've made your opinion clear so I have a different > > question then :-) Is there any timeframe you have in mind for this > > transition to happen? 2 years? 5 years? 10 years? Never? I *assume* > > there will come a time where 2.0.11 and 2.2.1 will have to die (i.e not > > be featured as download options). I would guess the transition would > > start at least then. > > Apache releases never die (which is why we cannot stop people (a.k.a. > fools) downloading Maven 2.1.0) > > We will probably drop the link for Maven 2.2.1 once we get to Maven 3.1 or > Maven 4.0 (depends on how big a change we think things are) > > I would suspect that a 3.1 or 4.0 might consider dropping support for JRE > 1.5 (given that 1.6 is nearing EOL) in which case we would probably retain > a link to the last version that only requires JRE 1.5 such as we are > currently doing for JRE 1.4 (i.e. the 2.0.11 link). Whether we would drop > the 2.0.11 link at that point in time is a different question. > > The links are there to help users that have specific requirements for Maven > versions, but there is absolutely nothing stopping anyone from going and > downloading the older versions, e.g. > http://archive.apache.org/dist/maven/binaries/ > > > -- > > Stanislav Ochotnicky <sochotni...@redhat.com> > > Software Engineer - Base Operating Systems Brno > > > > PGP: 7B087241 > > Red Hat Inc. http://cz.redhat.com > > > > --------------------------------------------------------------------- > > 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
