buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Wall" <steve.w...@primetimesoftware.com>
Subject Re: Referencing other buildr projects.
Date Wed, 02 Apr 2008 13:51:59 GMT
Something to keep in mind while creating a build structure, relative paths
introduce fragility. I'm referring to the "../" references. I know that's
not necessarily what's being proposed, I just wanted to point out that
practice causes problems in the long run. A cleaner solution provides a
central point defining variables for the root of each project. I've seen a
properties file used effectively. Essentially it allows you to move projects
in your build structure and you only have to change one place. It may seem
like a minor nit, but as build structures grow, you'll be thankful you
followed good fundamentals.

Steve

On Tue, Apr 1, 2008 at 6:39 PM, Assaf Arkin <arkin@intalio.com> wrote:

> 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