groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: What the... static compile by default
Date Fri, 11 May 2018 16:06:38 GMT
https://gitbox.apache.org/setup/

On Sat, May 12, 2018 at 12:59 AM, Mario Garcia <mario.ggar@gmail.com> wrote:

> Remko Could you add a link to Gitbox ?
>
> El vie., 11 may. 2018 a las 17:52, Remko Popma (<remko.popma@gmail.com>)
> escribió:
>
>> Over at Log4j we just decided to migrate from git-wip-us to gitbox
>> <http://mail-archives.apache.org/mod_mbox/logging-dev/201804.mbox/%3CCACmp6komnUBd-ug7durT7PoSAzgRzBy%2BpmGgWM_7BkMeaj6ksw%40mail.gmail.com%3E>
>> .
>>
>> Using gitbox will allow our projects to integrate better with GitHub
>>> including the ability to merge PRs directly from the site and the ability
>>> to push commits to GitHub and have them be automatically mirrored back to
>>> Apache.
>>
>>
>> This may be interesting for Groovy also.
>> We haven't made the move yet so I can't give you feedback from
>> first-hand experience.
>>
>> Remko
>>
>>
>> On Sat, May 12, 2018 at 12:32 AM, Mario Garcia <mario.ggar@gmail.com>
>> wrote:
>>
>>> *About Static Compilation changes:*
>>>
>>> I've used the way it's documented in the official documentation, and I
>>> agree with Cedric, I don't like having a system property. I see more
>>> benefits using the compiler configuration file:
>>>
>>>    - Configuration is more fine grained (apply to all, apply to some
>>>    classes, apply to some packages...)
>>>    - All compilation configuration can be found in one place. Having
>>>    more than one place to do this could be error prone, and harder to maintain.
>>>    - System properties are normally used when the process should vary
>>>    depending on the environment. In this case, I'm wondering why I would want
>>>    to compile my code statically in one environment but dynamically in
>>>    another. Maybe there is a case for that, but to me is weird.
>>>
>>> *About Daniel response:*
>>>
>>> I'm so sad to hear that Daniel. In the past few years I've been hearing
>>> only amazing things coming from your contributions.  Like someone has
>>> mentioned, Groovy 3 wouldn't be the same without you. I really hope you
>>> could reconsider your decision and keep contributing to Groovy.
>>>
>>> *About doing commits on master:*
>>>
>>> Reading the "Contributing code" section, at groovy-lang.org it seems
>>> everybody should be creating a local branch and to a MR afterwards over the
>>> remote version of that local branch. So  (again, reading the
>>> documentation)  nobody should be adding commits to master directly.
>>>
>>> I think merge requests are essential. I'm reading Jochen is saying that
>>> this is not very straight forward with Github. Could anyone please explain
>>> why ? Knowing the pains may help finding the solution.
>>>
>>> My two cents
>>> Mario
>>>
>>> El vie., 11 may. 2018 3:42, Thibault Kruse <tibokruse@googlemail.com>
>>> escribió:
>>>
>>>> It seems a bit weird to leave this thread dangling after the dramatic
>>>> entry scene.
>>>>
>>>> The activity on master branch seems to indicate some changes were
>>>> decided:
>>>>
>>>> danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
>>>> setting compileStatic by default via sys…
>>>> danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
>>>> checking and compilation fail when multiple …
>>>> danielsun1106 committed 14 hours ago : Simplify finding generics
>>>> implementation class
>>>>
>>>> However, the meta-concern by Cedric was not addressed it seems. Why is
>>>> anyone directly working on the master branch of groovy?
>>>> Is there a technical reason for this, rather than using feature
>>>> branches, code reviews, and merge approvals?
>>>> Or is it just that nobody would have time to review in a timely
>>>> fashion anyway, so it's either that or zero progress?
>>>>
>>>>
>>>> On Tue, May 8, 2018 at 7:43 AM, MG <mgbiz@arscreat.com> wrote:
>>>> > On 07.05.2018 17:54, Cédric Champeau wrote:
>>>> >>
>>>> >> I'd typically very much prefer a custom file extension for example.
>>>> >
>>>> >
>>>> > That would be my preferred way to give anyone a simple mean to choose
>>>> static
>>>> > compilation as the default for a Groovy file. Afair the counter
>>>> argument
>>>> > was, that Groovy compiles any file with any extension in dynamic mode
>>>> by
>>>> > default, so this might be a breaking change if someone has used the
>>>> picked
>>>> > extension for his files. Groovy 3.0 might be the right spot to
>>>> introduce
>>>> > something like this, since there will be breaking changes anyway...
>>>> >
>>>> >> That said, since I'm not contributing code anymore (my last
>>>> contribution
>>>> >> was rewriting most of the build, which I hope was helpful),
>>>> >
>>>> >
>>>> > Any improvement/speedup of the Gradle build was _definitely_
>>>> appreciated :-)
>>>> >
>>>> >> I'm happy to step down and let you work as you wish.
>>>> >
>>>> >
>>>> > This is tricky: One cannot agree with just any direction someone who
>>>> invests
>>>> > the time to advance Groovy wants to take it too, that would be taking
>>>> > Doocracy too far, imho, and might lead to a Groovy which is much
>>>> worse than
>>>> > it could be.
>>>> > In this particular case I am torn: I think we could definitely live
>>>> with the
>>>> > system property, I don't feel there is a large probability that it
>>>> will
>>>> > break anything. On the other hand, using the existing mechanism, or
>>>> > introducing a static compilation source file extension, or a compiler
>>>> switch
>>>> > seem to me to be the better choices - but maybe Daniel can explain
>>>> why he
>>>> > went with the property approach ?-)
>>>> >
>>>> > Cheers,
>>>> > mg
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>

Mime
View raw message