Anyway, moving on from gradle properties - I'm sure that will work out just fine. My vote is to add support for build.properties like we have now for users, I've said what I think beyond that (gradle.properties is for the gradle build), I don't think I'm needed anymore there.
In terms of your point about the build being too specialized or not, I agree. This is a big build, there is a lot going on. This is why I would not be comfortable putting the build in if others don't get involved. I expect plenty of points to come up. I expect we will get to talk about those points and come to a decision on what to do. I can talk past a lot of objects in a point by point response email chain, so I think it's best that we devote a JIRA to anything that people feel is important in order to focus an actionable discussion. I won't say that my way will win every JIRA, but I will say that I have thought about things very carefully in terms of what is relied on and what conventions or standards are broken. Even still, we might change things for style (there is plenty of subjective organizational things going on, I've been waiting for Uwe to improve them) or I missed something or was wrong. But I've spent some time in my head on this, so there is not just some weird important thing that only I will understand and if I get hit by a bus, on no. I see a lot of that everywhere I look and so I've made choices carefully actually. I'm super happy with most of the results, but there are likely better options for many things, I'd love to hear them. If there is something you feel you don't understand though: * Perhaps it's because you have only just started looking at a complex 60 module project build made to coexist with an existing complicated build and that takes a little time to get up to speed on always. * It's something that can be easily dropped and is not relied on. If it's something else, great, I'm looking for those most of all, let's hear em. - Mark
