Re: removing the settings.gradle file

>>> I think we should do away with the processing stage which figures  
>>> out which projects are included in the build, and simply allow  
>>> them to be added at any point during the evaluation stage. That  
>>> is, projects are just regular domain objects, not anything  
>>> special. I think this consistency important. In addition, this  
>>> would mean you can use plugins or classes in buildSrc to define or  
>>> influence the project hierarchy without us doing anything special  
>>> to support it. The same would be true of any future capability we  
>>> add to let you compose the build logic. To me, this approach seems  
>>> more flexible and more likely to handle use-cases we haven't  
>>> anticipated, than would special-casing assembly of the project  
>>> hierarchy.
>>
>> I'm trying to understand the lifecycle we would have then. Let's  
>> say we have a non aggregate multi-project build. All subprojects  
>> are declared in the root project. During the evaluation phase of  
>> the root project we hit the projects closure. After a declaration  
>> of each subproject, we would create an empty project instance for  
>> this subproject. After the projects closure is evaluated the root  
>> project can configure the sub projects. After the root project is  
>> evaluated, the subprojects are evaluated (let's say by default in  
>> alphabetical order). The evaluation order can be customized by  
>> calling the subproject.evaluate() method or by creating a dependsOn  
>> relation (for example because subproject1 needs an evaluated  
>> subproject2).
>
> Pretty much. To add a little more detail:
>
> for projects { subproject { ... } }
>
> when subproject { ... } is executed:
>
> 1. create a project descriptor
> 2. execute the closure to configure the project descriptor
> 3. execute the project { } closure from the subproject's build file,  
> if present, to configure the project descriptor
> 4. use the project descriptor to create an empty project and add to  
> parent project
> 5. fire a project added notification
> 6. repeat this process for any projects nested in the configure  
> closure.
>
> Step 3 is possibly not needed. Also, we could skip a project  
> descriptor and create a project in step 1 instead.