buildfile per component

[Ittay Dror]

Hi,

I have a large source tree with many modules grouped into components. Each developer knows only one component, so I don't want them to checkout and build the rest. However, the nightly build does need to checkout all.

How I can break the single buildfile into several so that the top buildfile just includes the ones in each component and they in turn define all modules (that is, i don't aim at a buildfile per module). Each one should be independent so I can checkout the component directory and build the component. Note that the top buildfile does have its own logic of defining the order of build according dependencies between sub buildfiles (if used independently they reference each other as artifacts) and creating bundles containing all components.

Thank you,
Ittay

[Assaf Arkin]

On Wed, Jun 25, 2008 at 1:23 AM, Ittay Dror <ittay.dror@...> wrote:

>
> Hi,
>
> I have a large source tree with many modules grouped into components. Each
> developer knows only one component, so I don't want them to checkout and
> build the rest. However, the nightly build does need to checkout all.
>
> How I can break the single buildfile into several so that the top buildfile
> just includes the ones in each component and they in turn define all modules
> (that is, i don't aim at a buildfile per module). Each one should be
> independent so I can checkout the component directory and build the
> component. Note that the top buildfile does have its own logic of defining
> the order of build according dependencies between sub buildfiles (if used
> independently they reference each other as artifacts) and creating bundles
> containing all components.

I have not tried this, but here's something worth trying and if it
ends up working, we can turn this into a feature.

Say the larger buildfile has a project master, and sub-directories foo
and bar, each with its own buildfile.  I'm guessing loading and
evaluating these inside the master project could work, like so:

define 'master' do
  eval File.load('foo/buildfile')
  eval File.load('bar/buildfile')
end

Assaf

>
> Thank you,
> Ittay
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Ittay Dror]

Assaf Arkin wrote:

On Wed, Jun 25, 2008 at 1:23 AM, Ittay Dror <[e-mail]> wrote:
>
> Hi,
>
> I have a large source tree with many modules grouped into components. Each
> developer knows only one component, so I don't want them to checkout and
> build the rest. However, the nightly build does need to checkout all.
>
> How I can break the single buildfile into several so that the top buildfile
> just includes the ones in each component and they in turn define all modules
> (that is, i don't aim at a buildfile per module). Each one should be
> independent so I can checkout the component directory and build the
> component. Note that the top buildfile does have its own logic of defining
> the order of build according dependencies between sub buildfiles (if used
> independently they reference each other as artifacts) and creating bundles
> containing all components.

I have not tried this, but here's something worth trying and if it
ends up working, we can turn this into a feature.

Say the larger buildfile has a project master, and sub-directories foo
and bar, each with its own buildfile.  I'm guessing loading and
evaluating these inside the master project could work, like so:

define 'master' do
  eval File.load('foo/buildfile')
  eval File.load('bar/buildfile')
end

Assaf

But then, if I cd to foo and try to build, buildr will see the buildfile and will use it as master, right? I think this will mess up project names. Maybe change the names to subbuildfile?

Assaf Arkin wrote:

>
> Thank you,
> Ittay
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Assaf Arkin]

On Fri, Jun 27, 2008 at 10:12 PM, Ittay Dror <ittay.dror@...> wrote:

>
>
>
> Assaf Arkin wrote:
>>
>> On Wed, Jun 25, 2008 at 1:23 AM, Ittay Dror <ittay.dror@...> wrote:
>>>
>>> Hi,
>>>
>>> I have a large source tree with many modules grouped into components.
>>> Each
>>> developer knows only one component, so I don't want them to checkout and
>>> build the rest. However, the nightly build does need to checkout all.
>>>
>>> How I can break the single buildfile into several so that the top
>>> buildfile
>>> just includes the ones in each component and they in turn define all
>>> modules
>>> (that is, i don't aim at a buildfile per module). Each one should be
>>> independent so I can checkout the component directory and build the
>>> component. Note that the top buildfile does have its own logic of
>>> defining
>>> the order of build according dependencies between sub buildfiles (if used
>>> independently they reference each other as artifacts) and creating
>>> bundles
>>> containing all components.
>>
>> I have not tried this, but here's something worth trying and if it
>> ends up working, we can turn this into a feature.
>>
>> Say the larger buildfile has a project master, and sub-directories foo
>> and bar, each with its own buildfile.  I'm guessing loading and
>> evaluating these inside the master project could work, like so:
>>
>> define 'master' do
>>   eval File.load('foo/buildfile')
>>   eval File.load('bar/buildfile')
>> end
>>
>> Assaf
>>
> But then, if I cd to foo and try to build, buildr will see the buildfile and
> will use it as master, right? I think this will mess up project names. Maybe
> change the names to subbuildfile?

Buildr looks for the buildfile in the current directory (up the tree
if there's none in the current directory), so inside foo you would
only get foo's buildfile to load.  At that point, you're like every
other component developer who only sees one buildfile and not the
entire set.

Assaf

>
>
>
> Assaf Arkin wrote:
>>
>>
>>>
>>> Thank you,
>>> Ittay
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Ittay Dror]

Assaf Arkin wrote:

On Fri, Jun 27, 2008 at 10:12 PM, Ittay Dror <[e-mail]> wrote:
>
>
>
> Assaf Arkin wrote:
>>
>> On Wed, Jun 25, 2008 at 1:23 AM, Ittay Dror <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> I have a large source tree with many modules grouped into components.
>>> Each
>>> developer knows only one component, so I don't want them to checkout and
>>> build the rest. However, the nightly build does need to checkout all.
>>>
>>> How I can break the single buildfile into several so that the top
>>> buildfile
>>> just includes the ones in each component and they in turn define all
>>> modules
>>> (that is, i don't aim at a buildfile per module). Each one should be
>>> independent so I can checkout the component directory and build the
>>> component. Note that the top buildfile does have its own logic of
>>> defining
>>> the order of build according dependencies between sub buildfiles (if used
>>> independently they reference each other as artifacts) and creating
>>> bundles
>>> containing all components.
>>
>> I have not tried this, but here's something worth trying and if it
>> ends up working, we can turn this into a feature.
>>
>> Say the larger buildfile has a project master, and sub-directories foo
>> and bar, each with its own buildfile.  I'm guessing loading and
>> evaluating these inside the master project could work, like so:
>>
>> define 'master' do
>>   eval File.load('foo/buildfile')
>>   eval File.load('bar/buildfile')
>> end
>>
>> Assaf
>>
> But then, if I cd to foo and try to build, buildr will see the buildfile and
> will use it as master, right? I think this will mess up project names. Maybe
> change the names to subbuildfile?

Buildr looks for the buildfile in the current directory (up the tree
if there's none in the current directory), so inside foo you would
only get foo's buildfile to load.  At that point, you're like every
other component developer who only sees one buildfile and not the
entire set.

Assaf

can I reference 'bar' as a dependency? usually this is done with 'project()', but if i build in 'foo', then 'bar' is unknown. in maven, since a dependency is always via group,artifact,version ids, it does not matter, as long as 'bar' is in the local repository. how can i get the same behavior in buildr?

thanks,
ittay

Assaf Arkin wrote:

>
>
>
> Assaf Arkin wrote:
>>
>>
>>>
>>> Thank you,
>>> Ittay
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Assaf Arkin]

On Sun, Jun 29, 2008 at 2:36 PM, Ittay Dror <ittay.dror@...> wrote:

>
>
>
> Assaf Arkin wrote:
>>
>> On Fri, Jun 27, 2008 at 10:12 PM, Ittay Dror <ittay.dror@...> wrote:
>>>
>>>
>>>
>>> Assaf Arkin wrote:
>>>>
>>>> On Wed, Jun 25, 2008 at 1:23 AM, Ittay Dror <ittay.dror@...>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have a large source tree with many modules grouped into components.
>>>>> Each
>>>>> developer knows only one component, so I don't want them to checkout
>>>>> and
>>>>> build the rest. However, the nightly build does need to checkout all.
>>>>>
>>>>> How I can break the single buildfile into several so that the top
>>>>> buildfile
>>>>> just includes the ones in each component and they in turn define all
>>>>> modules
>>>>> (that is, i don't aim at a buildfile per module). Each one should be
>>>>> independent so I can checkout the component directory and build the
>>>>> component. Note that the top buildfile does have its own logic of
>>>>> defining
>>>>> the order of build according dependencies between sub buildfiles (if
>>>>> used
>>>>> independently they reference each other as artifacts) and creating
>>>>> bundles
>>>>> containing all components.
>>>>
>>>> I have not tried this, but here's something worth trying and if it
>>>> ends up working, we can turn this into a feature.
>>>>
>>>> Say the larger buildfile has a project master, and sub-directories foo
>>>> and bar, each with its own buildfile.  I'm guessing loading and
>>>> evaluating these inside the master project could work, like so:
>>>>
>>>> define 'master' do
>>>>   eval File.load('foo/buildfile')
>>>>   eval File.load('bar/buildfile')
>>>> end
>>>>
>>>> Assaf
>>>>
>>> But then, if I cd to foo and try to build, buildr will see the buildfile
>>> and
>>> will use it as master, right? I think this will mess up project names.
>>> Maybe
>>> change the names to subbuildfile?
>>
>> Buildr looks for the buildfile in the current directory (up the tree
>> if there's none in the current directory), so inside foo you would
>> only get foo's buildfile to load.  At that point, you're like every
>> other component developer who only sees one buildfile and not the
>> entire set.
>>
>> Assaf
>>
>
> can I reference 'bar' as a dependency? usually this is done with
> 'project()', but if i build in 'foo', then 'bar' is unknown. in maven, since
> a dependency is always via group,artifact,version ids, it does not matter,
> as long as 'bar' is in the local repository. how can i get the same behavior
> in buildr?

You don't change the buildfile.  If right now foo's buildfile
references bar by its artifact specification, it keeps doing the same
thing.

When you use the project reference it also references the artifact by
its specification, it's just a very convenient shortcut which you can
use inside, but not across buildfiles.

Assaf

>
> thanks,
> ittay
>
>
> Assaf Arkin wrote:
>>
>>
>>>
>>>
>>>
>>> Assaf Arkin wrote:
>>>>
>>>>
>>>>>
>>>>> Thank you,
>>>>> Ittay
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18185612.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Ittay Dror]

Assaf Arkin wrote:

[SNIP]
>>
>> Buildr looks for the buildfile in the current directory (up the tree
>> if there's none in the current directory), so inside foo you would
>> only get foo's buildfile to load.  At that point, you're like every
>> other component developer who only sees one buildfile and not the
>> entire set.
>>
>> Assaf
>>
>
> can I reference 'bar' as a dependency? usually this is done with
> 'project()', but if i build in 'foo', then 'bar' is unknown. in maven, since
> a dependency is always via group,artifact,version ids, it does not matter,
> as long as 'bar' is in the local repository. how can i get the same behavior
> in buildr?

You don't change the buildfile.  If right now foo's buildfile
references bar by its artifact specification, it keeps doing the same
thing.

When you use the project reference it also references the artifact by
its specification, it's just a very convenient shortcut which you can
use inside, but not across buildfiles.

Assaf

Which was what I was pointing to: I have modules foo and bar, foo depends on bar. If I write a single buildfile, then in foo's define I can reference bar with 'project(bar)'. If I split the build file so there are root/buildfile, root/foo/buildfile, root/bar/buildfile and build from root, everything works the same. But if I just want to build 'foo', I cd to foo and then buildr will pickup only root/foo/buildfile. Then, when it sees 'project("bar")' it will trigger an error, because it doesn't know bar (at least that is what I understand from looking at the source code).

So root/bar/buildfile should be evaluated also.

There are two ways that I think of:
1. the "user" way: rename root/foo/buildfile and root/bar/buildfile to root/foo/buildfile.sub and root/bar/buildfile.sub. then when building in foo builr will still read the file from root/buildfile
2. the "framework" way: when referencing an unknown project, try to search the directories for a directory with the same name as the project and read the buildfile from there. this means buildr needs to know the root from which to search, maybe by requiring a root.buildr file to be placed there. then, if in root/foo/buildfile, buildr sees 'project("bar")', it will try to read root/bar/buildfile, finding the definition of bar there and all is well

The second way is better for complex projects since it requires reading only those projects that are required as dependencies by the project that is currently being built.

Unfortunately, I do not yet know enough Ruby / Rake / Buildr to try to attempt this change myself.

Ittay

Assaf Arkin wrote:

>
> thanks,
> ittay
>
>
> Assaf Arkin wrote:
>>
>>
>>>
>>>
>>>
>>> Assaf Arkin wrote:
>>>>
>>>>
>>>>>
>>>>> Thank you,
>>>>> Ittay
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18185612.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Assaf Arkin]

On Sun, Jun 29, 2008 at 9:56 PM, Ittay Dror <ittay.dror@...> wrote:
>>
> Which was what I was pointing to: I have modules foo and bar, foo depends on
> bar. If I write a single buildfile, then in foo's define I can reference bar
> with 'project(bar)'. If I split the build file so there are root/buildfile,
> root/foo/buildfile, root/bar/buildfile and build from root, everything works
> the same. But if I just want to build 'foo', I cd to foo and then buildr
> will pickup only root/foo/buildfile. Then, when it sees 'project("bar")' it
> will trigger an error, because it doesn't know bar (at least that is what I
> understand from looking at the source code).

Let's say you have a buildfile for foo that's standalone.  It
references artifacts built by bar, but it doesn't know about bar's
buildfile, projects, etc.  Only that some artifacts (which bar happens
to produce) are necessary.  It's possible to have a master buildfile
that can build both by including them from a parent directory.  (I've
yet to try it myself, but looks like it will work)

That way you can checkout foo and built it, or checkout bar and build
it, or checkout the parent and build both.

Different thing if you want foo and bar to know about each other,
reference the projects, etc.  Then both have to be part of the same
buildfile, conceptually.  You can split a buildfile into as many small
files as you want, but they all have to load together.  In this case
you have to check out the parent because building the parent would
require building foo and bar.

Assaf

>
> So root/bar/buildfile should be evaluated also.
>
> There are two ways that I think of:
> 1. the "user" way: rename root/foo/buildfile and root/bar/buildfile to
> root/foo/buildfile.sub and root/bar/buildfile.sub. then when building in foo
> builr will still read the file from root/buildfile
> 2. the "framework" way: when referencing an unknown project, try to search
> the directories for a directory with the same name as the project and read
> the buildfile from there. this means buildr needs to know the root from
> which to search, maybe by requiring a root.buildr file to be placed there.
> then, if in root/foo/buildfile, buildr sees 'project("bar")', it will try to
> read root/bar/buildfile, finding the definition of bar there and all is well
>
> The second way is better for complex projects since it requires reading only
> those projects that are required as dependencies by the project that is
> currently being built.
>
> Unfortunately, I do not yet know enough Ruby / Rake / Buildr to try to
> attempt this change myself.
>
> Ittay
>
>
> Assaf Arkin wrote:
>>
>>>
>>> thanks,
>>> ittay
>>>
>>>
>>> Assaf Arkin wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Assaf Arkin wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Ittay
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18185612.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18188699.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Ittay Dror]

Assaf Arkin wrote:

On Sun, Jun 29, 2008 at 9:56 PM, Ittay Dror <[e-mail]> wrote:
>>
> Which was what I was pointing to: I have modules foo and bar, foo depends on
> bar. If I write a single buildfile, then in foo's define I can reference bar
> with 'project(bar)'. If I split the build file so there are root/buildfile,
> root/foo/buildfile, root/bar/buildfile and build from root, everything works
> the same. But if I just want to build 'foo', I cd to foo and then buildr
> will pickup only root/foo/buildfile. Then, when it sees 'project("bar")' it
> will trigger an error, because it doesn't know bar (at least that is what I
> understand from looking at the source code).

Let's say you have a buildfile for foo that's standalone.  It
references artifacts built by bar, but it doesn't know about bar's
buildfile, projects, etc.  Only that some artifacts (which bar happens
to produce) are necessary.  It's possible to have a master buildfile
that can build both by including them from a parent directory.  (I've
yet to try it myself, but looks like it will work)

That way you can checkout foo and built it, or checkout bar and build
it, or checkout the parent and build both.

Different thing if you want foo and bar to know about each other,
reference the projects, etc.  Then both have to be part of the same
buildfile, conceptually.  You can split a buildfile into as many small
files as you want, but they all have to load together.  In this case
you have to check out the parent because building the parent would
require building foo and bar.

Assaf

Fair enough and I agree with all your points.

I do however have an idea which I wrote before but may have been obscured by the talk about separating build files:

Today in buildr I have two modes: compile all and compile a project group (cd to the group's directory and run buildr)

But, what if there are dependencies between modules and groups? Say I have an application with 'common', 'server' and 'client' modules (or group of modules). It would be nice if I could tell buildr to build 'server' and all its dependencies and it would build 'common'. or, if i cd into one of the server modules and build it, it will also build those modules in common which it depends on. this is good for source trees with high modularization (for example a framework that has a lot of plugins - it will be a waste of time to build everything just for one plugin). I know this may cause consistency problems ('common' might have changes that break 'client'), but I think the flexibility this brings is good (I know of one project that will benefit from such a feature).

So, if in 'server' buildfile i use 'project("common")', and 'common' is not found in @projects, then buildr can try to load the buildfile from root/common.

What is your view?

Ittay

Assaf Arkin wrote:

>
> So root/bar/buildfile should be evaluated also.
>
> There are two ways that I think of:
> 1. the "user" way: rename root/foo/buildfile and root/bar/buildfile to
> root/foo/buildfile.sub and root/bar/buildfile.sub. then when building in foo
> builr will still read the file from root/buildfile
> 2. the "framework" way: when referencing an unknown project, try to search
> the directories for a directory with the same name as the project and read
> the buildfile from there. this means buildr needs to know the root from
> which to search, maybe by requiring a root.buildr file to be placed there.
> then, if in root/foo/buildfile, buildr sees 'project("bar")', it will try to
> read root/bar/buildfile, finding the definition of bar there and all is well
>
> The second way is better for complex projects since it requires reading only
> those projects that are required as dependencies by the project that is
> currently being built.
>
> Unfortunately, I do not yet know enough Ruby / Rake / Buildr to try to
> attempt this change myself.
>
> Ittay
>
>
> Assaf Arkin wrote:
>>
>>>
>>> thanks,
>>> ittay
>>>
>>>
>>> Assaf Arkin wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Assaf Arkin wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Ittay
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18185612.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18188699.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>

[Assaf Arkin]

On Mon, Jun 30, 2008 at 4:14 AM, Ittay Dror <ittay.dror@...> wrote:

> Fair enough and I agree with all your points.
>
> I do however have an idea which I wrote before but may have been obscured by
> the talk about separating build files:
>
> Today in buildr I have two modes: compile all and compile a project group
> (cd to the group's directory and run buildr)
>
> But, what if there are dependencies between modules and groups? Say I have
> an application with 'common', 'server' and 'client' modules (or group of
> modules). It would be nice if I could tell buildr to build 'server' and all
> its dependencies and it would build 'common'.

It already does that. If there's any dependency it knows how to build,
it will build it.  You get that when you have several projects in the
same buildfile.

Assaf

 or, if i cd into one of the

> server modules and build it, it will also build those modules in common
> which it depends on. this is good for source trees with high modularization
> (for example a framework that has a lot of plugins - it will be a waste of
> time to build everything just for one plugin). I know this may cause
> consistency problems ('common' might have changes that break 'client'), but
> I think the flexibility this brings is good (I know of one project that will
> benefit from such a feature).
>
> So, if in 'server' buildfile i use 'project("common")', and 'common' is not
> found in @projects, then buildr can try to load the buildfile from
> root/common.
>
> What is your view?
>
> Ittay
>
>
> Assaf Arkin wrote:
>>
>>
>>>
>>> So root/bar/buildfile should be evaluated also.
>>>
>>> There are two ways that I think of:
>>> 1. the "user" way: rename root/foo/buildfile and root/bar/buildfile to
>>> root/foo/buildfile.sub and root/bar/buildfile.sub. then when building in
>>> foo
>>> builr will still read the file from root/buildfile
>>> 2. the "framework" way: when referencing an unknown project, try to
>>> search
>>> the directories for a directory with the same name as the project and
>>> read
>>> the buildfile from there. this means buildr needs to know the root from
>>> which to search, maybe by requiring a root.buildr file to be placed
>>> there.
>>> then, if in root/foo/buildfile, buildr sees 'project("bar")', it will try
>>> to
>>> read root/bar/buildfile, finding the definition of bar there and all is
>>> well
>>>
>>> The second way is better for complex projects since it requires reading
>>> only
>>> those projects that are required as dependencies by the project that is
>>> currently being built.
>>>
>>> Unfortunately, I do not yet know enough Ruby / Rake / Buildr to try to
>>> attempt this change myself.
>>>
>>> Ittay
>>>
>>>
>>> Assaf Arkin wrote:
>>>>
>>>>>
>>>>> thanks,
>>>>> ittay
>>>>>
>>>>>
>>>>> Assaf Arkin wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Assaf Arkin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Ittay
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18107287.html
>>>>>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18167540.html
>>>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/buildfile-per-component-tp18107287p18185612.html
>>>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/buildfile-per-component-tp18107287p18188699.html
>>> Sent from the Buildr - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/buildfile-per-component-tp18107287p18193377.html
> Sent from the Buildr - User mailing list archive at Nabble.com.
>
>