buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Billemont <lhun...@gmail.com>
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  
buildfile.

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  
Y.

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

~lhunath


On 01 Apr 2008, at 04:35, Assaf Arkin wrote:
> On Mon, Mar 31, 2008 at 6:52 AM, Maarten Billemont <lhunath@gmail.com>
> 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 <lhunath@gmail.com 
>>> >
>>> 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
>>>>
>>>>
>>


Mime
View raw message