buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Buildr always invokes all projects
Date Wed, 30 Jul 2008 18:00:50 GMT
On Wed, Jul 30, 2008 at 1:27 AM, Ittay Dror <ittay.dror@gmail.com> wrote:
> If I have projects A and B in a buildfile and I cd to A and build, B's
> definition is invoked.
>
> If I understand correctly, this is done because the 'initialize' task calls
> the 'projects' method which invokes all project tasks. Is this necessary in
> this case? As far as I understand, whenever a project definition refers to
> another project (#project and #projects methods), the other project is
> invoked, thus defining it. And local tasks call local_projects, which can
> invoke those projects then. All nice and lazy.

local_projects looks for all the projects defined to have the same
base directory as the current working directory, which requires
knowing all the projects in the buildfile (there are a few other
things that depend on that as well).  Project definitions can be
nested and overlapping, because of that we have to evaluate all of
them.

> I know that I can implement the project's definition, so it does things
> lazily (create only entry tasks which when invoked create and invoke other
> tasks). But it will be more straight forward for me if buildr provides this.

You have four places, depending on when dependencies come to existence:
1.  Before the definition (before_define) if you can determine it
early on (e.g. src/main/java)
2.  During the definition, for stuff the definition can affect (e.g.
compile.with)
3.  After the definition (after_define) for anything dependent on the
definition (e.g. finding out the actual compile.target)
4.  When running, for anything that doesn't exist without another task
executing first (e.g. find all the .xml files in resources.target)

So that's definitely quite complex, it makes building extensions
harder but it makes the developer's life easier.  For example, it
allows you to change compile.dependencies during the definition and
have test.dependencies pick up on those changes in after_define.

And some parts are unavoidable.  For example, all the zip (packaging)
tasks can't build their prerequisite until very later because the
files they depend on don't exist without first compiling the source
code.  They have to cache all these dependencies and then expand them
into prerequisites.

Assaf

>
> Thanks,
> Ittay
>
> --
> --
> Ittay Dror <ittay.dror@gmail.com>
>
>
>

Mime
View raw message