Buildr always invokes all projects

[Ittay Dror <it...@gmail.com>]

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.

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.

Thanks,
Ittay

-- 
--
Ittay Dror <it...@gmail.com>

Re: Buildr always invokes all projects

[Assaf Arkin <ar...@intalio.com>]

On Wed, Jul 30, 2008 at 1:27 AM, Ittay Dror <it...@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 <it...@gmail.com>
>
>
>