Re: removing the settings.gradle file

>
> On May 23, 2009, at 11:32 PM, Adam Murdoch wrote:
>
>> Hi,
>>
>> I'd like to come up with a plan for removing the settings.gradle file.
>>
>> (apologies for the essay - I think this stuff needs to be considered
>> as a whole)
>>
>> There's 5 things we use settings.gradle for, which we will need
>> replacements for:
>>
>> 1. Defining the project heirarchy. That is, which projects are
>> included in thie build?
>>
>> 2. Defining the project descriptor for each project in the build.
>> That is, what is the project name, build file, project dir and build
>> dir for each project?
>>
>> 3. Defining the build script classpath(s). That is, which classes are
>> available at compilation time and execution time for each build script.
>
> And right now there is the additional constraint, that there is only
> one build script classpath for all of the build scripts of a
> multi-project build.
>
>>
>> 4. Defining the classpath(s) for custom plugins to be used in the
>> build script. Currently we use the build script classpath for the
>> custom plugin classpath, but I think they really are separate use cases.
>>
>> 5. Locating the root project of the build when running from the
>> command-line.
>>
>> Plus, the solution should allow us to later add better ways of
>> composing the build and plugin classpaths, such as by using project
>> dependencies.
>>
>> I have some suggestions, but they're really just a starting point for
>> discussion.
>>
>>
>> * Defining the heirarchy
>>
>> It would be useful, I think, for any project to be able to define its
>> own subprojects. This allows for better build encapsulation, and
>> would allow small builds to be more easily composed into multiple
>> larger builds. Perhaps something like this in the build file:
>>
>> projects {
>>  subProject {
>>     buildFile = 'sub-project.gradle'
>>  }
>>  anotherSubProjectUsingDefaults
>>  aSubProjectConfiguredUsingAMap(projectDir: 'sub', buildFile:
>> 'sub.gradle')
>> }
>>
>> This could be nested to allow a project tree to be specified:
>>
>> projects {
>>   subProject {
>>       anotherProject { ... }
>>   }
>> }
>
> I think a builder syntax is a natural way to express and configure a
> project hierarchy.
>
> I think having aggregate multi-project builds are very important. I
> see two types of multiproject builds. One is a strongly coupled one,
> where the subprojects depend on the configuration of the parent
> project and where artifact project dependencies are used. This is well
> supported in Gradle at the moment. The other type of multi-project
> build is much more loosely coupled. The subprojects don't know of each
> other and can be build independently. Artifacts dependencies are
> realized as external dependencies. An aggregate multi-project build
> will often contain both types of multi-project builds. Those aggregate
> builds are an important requirement on our way to become a good build
> integration tool.
>
> Right now we have the behavior that only the root and the leafs of the
> project hierarchy need to be specified. The nodes in between are
> automatically created. I don't think this makes a lot of sense. I just
> want to mention it.
>
>> 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).