buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Referencing other buildr projects.
Date Wed, 02 Apr 2008 00:39:49 GMT
On Tue, Apr 1, 2008 at 1:01 AM, Maarten Billemont <lhunath@gmail.com> wrote:

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


Yes.  Neither one will work for now, because the root directory will be
wrong.  The only solution for now, until we figure something out, is to have
one buildfile managing both projects.

Assaf


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


-- 
CTO, Intalio
http://www.intalio.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message