*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 <tibokr...@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 <mg...@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 > > > > > > >
