Mailing-List: contact buildr-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: buildr-user@incubator.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 arkin@intalio.com does not designate 72.14.220.154 as permitted sender)
Message-ID: <3de5d7d20803311935t1d29aedcg521be0bea921ba7e@mail.gmail.com>
Date: Mon, 31 Mar 2008 19:35:06 -0700
From: "Assaf Arkin" <arkin@intalio.com>
To: buildr-user@incubator.apache.org
Subject: Re: Referencing other buildr projects.
In-Reply-To: <00295A5B-ABEC-4C7E-B3E3-C806F870CBC6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7089_14299756.1207017306263"
References: <0FE1487C-A34E-46FC-B450-32CE0085F6FF@gmail.com>
	 <4c1d6a900803301744g21b34079reb31582e747364c2@mail.gmail.com>
	 <00295A5B-ABEC-4C7E-B3E3-C806F870CBC6@gmail.com>

------=_Part_7089_14299756.1207017306263
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_7089_14299756.1207017306263--