groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Garcia <mario.g...@gmail.com>
Subject Re: What the... static compile by default
Date Fri, 11 May 2018 15:59:19 GMT
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