[ . . . ] > 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:[email protected] London SW11 1EN, UK. m: +44 7770 465 077 xmpp: [email protected]
signature.asc
Description: This is a digitally signed message part
