Given the funding of groovy changed last year, this situation will show what kind of support exists. I know my PRs are growing long beards. Maybe work on this could be modularized in smaller milestones, and be pursues over kickstarter or GSoC.
Also I remember another discussion where I put forward the idea of reducing the core codebase. Meaning to split out things like groovysh. It's not ideal maybe, but this might be a 'pick the lesser of two evils' situation. On Thursday, November 26, 2015, Guillaume Laforge <[email protected]> wrote: > I'm also thinking it's the right moment to "fix" things we've done wrong, > have a clean separation, not leaking implementation, etc. > That's feeling like the right moment to seize this opportunity. We > wouldn't keep the odd location of some of the classes we've already > mentioned. And as Cédric says, we could also offer a converter in a way or > another to help the migration. > People fear transitions like Python 2 to 3 would happen as soon as we > break compatibility, but the differences between Python 2 and 3 were much > bigger that what we're speaking about here. > > On Thu, Nov 26, 2015 at 8:49 PM, Cédric Champeau < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Honestly I don't think 1 or 2 is reasonable. The simple example of XML is >> enough to show the damage. We won't be able to have a separate XML module. >> That defeats the concepts of modules. Also it would lead to bigger jars, >> which is something we want to avoid as much as possible. Last but not >> least, the more I think about it, the more I think it's the event that we >> were all waiting for to finally do the breaking changes we've thought of >> for years. Eventually, we could come up with a smoother migration path, by >> providing an automatic source converter (remapping packages). It would have >> the same advantages as the ones Rémi talked about. >> >> 2015-11-26 19:18 GMT+01:00 Pascal Schumacher <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>>: >> >>> Thanks for the detailed analysis Cédric. :) >>> >>> Am 26.11.2015 um 13:10 schrieb Cédric Champeau: >>> >>>> So what can we do? >>>> >>>> 1. the easiest, fastest path, is to kill all modules that we have >>>> today, and go with a single, good old, groovy-all jar. We would go years >>>> backwards, and it's definitely not something we want to do. We want to have >>>> *more* modularization, in particular for Android, where the current split >>>> is still too big. >>>> 2. refactor modules so that each module has its own set of packages, >>>> and hope that we don't end up with a big groovy-all jar. Seems very >>>> unlikely. >>>> 3. break binary compatibility, move classes around, reorganize stuff. >>>> >>> >>> Am 26.11.2015 um 14:16 schrieb Jochen Theodorou: >>> >>>> I think we should concentrate on solving the package name conflicts in >>>> the new module system first... which basically is route 2. I am pretty sure >>>> the jdk9 problems won't end there and we need time to solve these problems >>>> as well... Of course we could still think about getting rid of the callsite >>>> caching part and depend on say JDK7 as minimum version. >>>> >>> >>> I agree, we should try option 2 or - if it's nearly the same as option 1 >>> - take option 1. >>> >>> I think option 3 is the worst. With our current lack of resources I >>> doubt that we could implement enough "killer" features to motivate people >>> to update (getting people to update would be difficult anyway). >>> >>> Cheers, >>> Pascal >>> >> >> > > > -- > Guillaume Laforge > Apache Groovy committer & PMC member > Product Ninja & Advocate at Restlet <http://restlet.com> > > Blog: http://glaforge.appspot.com/ > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> >
