groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: challenges through Java modules (aka jigsaw)
Date Sat, 28 Nov 2015 09:01:51 GMT
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
<tibokruse@googlemail.com> 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 <glaforge@gmail.com>
> 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
>> <cedric.champeau@gmail.com> 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 <pascalschumacher@gmx.net>:
>>>>
>>>> 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+

Mime
View raw message