On Jun 3, 2009, at 11:15 AM, Adam Murdoch wrote:
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.
Right. That would simplify things. We would expose the whole project
API by that. But that would be a feature. And parts of the API which
are not supposed to be used at that lifecycle phase can be shielded
with an exception.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
