On Sat, May 12, 2018 at 12:59 AM, Mario Garcia <> wrote:
Remko Could you add a link to Gitbox ?

El vie., 11 may. 2018 a las 17:52, Remko Popma (<>) escribió:
Over at Log4j we just decided to migrate from git-wip-us to gitbox

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.


On Sat, May 12, 2018 at 12:32 AM, Mario Garcia <> 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 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

El vie., 11 may. 2018 3:42, Thibault Kruse <> 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 <> 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