buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Billemont <>
Subject Re: Referencing other buildr projects.
Date Tue, 01 Apr 2008 08:01:31 GMT
Just to be sure I'm not messing up here, seeing as I don't really know  
any ruby as of yet.

Should I add a 'require ../X/buildfile' to project Y, or will that  
break buildr?  I imagine that when buildr loads the X buildfile it  
will not be able to find the projects defined in it since it is still  
using the Y project root as base for relative paths used in X's  

Should I just create a topmost buildfile in the root of both X and Y,  
which does a require */buildfile?  Is that even legal syntax?  Or just  
a require 'X/buildfile' require 'Y/buildfile'.  But then I'm still  
plagued with the fact that the base dir for those buildfiles will be  
the root of my projects, and not the root of respectively project X or  

I hope I make more sense than I think I am.


On 01 Apr 2008, at 04:35, Assaf Arkin wrote:
> On Mon, Mar 31, 2008 at 6:52 AM, Maarten Billemont <>
> wrote:
>> Is it possible to have a common buildfile in root and a buildfile  
>> for both
>> project X and Y?  For as little as I know buildr so far, I don't  
>> think so.
>> I was considdering the possibility of adding a require '../X/ 
>> buildfile'
>> but that would probably be a bad idea even if it did work.
>> The main problem I have with referencing X:b as an artifact instead  
>> of as
>> a project is that I loose several buildr dependency management  
>> capabilities
>> and when I do a buildr eclipse, I will have a dependency on a JAR,  
>> not the
>> source of that JAR.  Also, it's far more annoying to develop on both
>> projects that way, since changes to X:b only have an effect on Y  
>> after
>> buildr install'ing X:b.
>> I'm hoping to avoid all that by being able to reference to X:b as a
>> project instead of as an artifact.
> To do anything useful, Buildr would have to know all the tasks in both
> buildfiles, so it can execute only those tasks that need executing.   
> That
> means if will have to load both at once to make any sense of the
> dependencies, which is not much different from loading one buildfile  
> with
> both project definitions.
> Having one buildfile is just easier to manage.
> Assaf
>> On 31 Mar 2008, at 02:44, Alexis Midon wrote:
>>> I would say you need a common buildfile at the root level or you can
>>> reference the artifact X:b instead of the project.
>>> On Sun, Mar 30, 2008 at 3:07 PM, Maarten Billemont < 
>>> >
>>> wrote:
>>> My situation is like this:
>>>> root
>>>> |
>>>> |-- X
>>>> |   |-- X:a
>>>> |   |-- X:b
>>>> |
>>>> |
>>>> |-- Y
>>>> X is a project with subprojects.  Only the subprojects contain  
>>>> source
>>>> code.
>>>> Now I want Y to depend on one of the subprojects of X because it  
>>>> uses
>>>> a few classes from there (X is basically my library project  
>>>> containing
>>>> a few convenience utility classes, classified by subject in
>>>> subprojects.
>>>> X has a buildfile and Y has a buildfile.
>>>> root does not have a buildfile, nor do X:a and X:b, the latter  
>>>> two are
>>>> defined in the X buildfile - obviously.
>>>> Now my question is:  How do I declare a dependency of Y on X:b, for
>>>> example?
>>>> ~lhunath

View raw message