Re: removing the settings.gradle file

[ . . . ]
> One of the reasons that we have our own fork of Gradle currently is that we
> needed to be able to programmatically construct the set of projects used in a
> build.  We would like to to accomplish the same goals with this, but it looks
> like you may be planning to use AST transformations or another compile time
> technique to implement your scheme.  If so, please provide an API oriented
> alternative.
[ . . . ]

Having a fork already at this stage in the life of a project is clearly
not a good thing.  Hopefully there is a way of reconciling this issue so
that we can return to having a single mainline.

I appreciate this email is not contributing anything technical to the
debate I just wanted to point out the need to avoid a fork that is not a
friendly, and temporary, one.

--
Russel.
============================================================
Dr Russel Winder                 Partner

Concertant LLP          t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,     f: +44 8700 516 084    voip:  sip:russel.winder@...
London SW11 1EN, UK.    m: +44 7770 465 077    xmpp: russel@...