maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Updating dependencies on Maven 2.x to Maven 3.x in plugins?
Date Fri, 17 Aug 2012 11:37:47 GMT
On 17 August 2012 12:32, Stephen Connolly
<stephen.alan.connolly@gmail.com>wrote:

> On 17 August 2012 11:33, Stanislav Ochotnicky <sochotnicky@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 side note is that I hope to expose the features of jszip-maven-plugin as
an extension to Maven that other Maven plugins can leverage, in which case
even if jszip-maven-plugin is not used by anyone, the API that I hope to
develop may well end up widely in use and as different plugin's pick up its
features that will drive upgrading.


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

Another point is that Peter Reilly (from Apache ANT) wrote a Jenkins (née
Hudson) plugin many years ago which he compiled and ran against version
1.128 or something like that.

That plugin *still* works on Jenkins 1.475 unmodified (you just have to
compile it with the 1.128 toolchain)

That is a successful API


>
>> 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 <sochotnicky@redhat.com>
>> Software Engineer - Base Operating Systems Brno
>>
>> PGP: 7B087241
>> Red Hat Inc.                               http://cz.redhat.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message