groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Maven coordinates going forward
Date Mon, 27 Mar 2017 18:20:26 GMT
On 27.03.2017 20:08, Winnebeck, Jason wrote:
> The key thing in my mind is that you can't make a change that breaks
> 100% of libraries at one time without fracturing the community or at
> least introducing a major hindrance to upgrade that will mean
> maintaining 2.x series for a very long time. Even if the upgrade
> process is as easy as a recompile, there are a lot of published
> libraries no longer maintained. Even for the ones that are
> maintained, there are people who might not want to be forced to
> upgrade every library. I'm not a Grails user, but my impression is
> that the framework relies on a lot of plugins and is one of the (if
> not the most) active Groovy communities and I have a hard time
> envisioning how that upgrade path will take. You'd have to maintain
> Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd
> have to upgrade everything at one time to the (most likely) latest
> version.
>
> What is the possibility that the package names are changed, the
> parser, metaprogramming model, etc. that all break in Groovy 3
> change, but yet still have a compatibility JAR implementing the
> minimal Groovy 2.x classes in a way that allows interoperability with
> Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able
> to view Groovy 2 classes the same way as any other Java class. I
> think many concerns would be lifted if Groovy 2 and 3 could co-exist
> at the same time, allowing you to upgrade incrementally.

If you see the new metaprogramming model as chance, then it would make 
sense to implement that in the new packages instead of transferring old 
and to be deprecated classes. The goal would the to be able to run old 
and new system at the same time, where the Groovy 1.x/2.x classes would 
use Groovy 3.x/4.x classes as implementation.

The problem with this approach is simply manpower and of course some 
conceptual problems still to be solved.

bye Jochen

Mime
View raw message