Also, before starting refactorings it might be usefule to put up oracle JDK builds on TeamCity. I have no idea why that's not already being done, but it does not seem wise to me.
On Sat, Nov 28, 2015 at 9:12 AM, Thibault Kruse <[email protected]> wrote: > 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]> 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]>: >>>> >>>> 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 >> >> Blog: http://glaforge.appspot.com/ >> Social: @glaforge / Google+
