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 15:52:22 GMT
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