ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: ant 1.5.4 : Import
Date Fri, 25 Jul 2003 15:23:51 GMT
Guys, I think you are missing the point completely
on this discussion. I do not understand why are you trying
to impose your coding-style preferences for ANT on other
people by forcing things like importable and so forth.

The issue here is very simple, suppose I have the following

<project name="e">
 <import file="../f/build.xml"/>

<project name="f">
 <echo>Here is F!</echo>

<project name="r">
  <import file="/a/b/c/d/e/build.xml"/>

<project name="v">
 <import file="/a/b/c/d/e/build.xml"/>

Now, /a/b/c/d directory contains the installation of some useful library
of ANT code scripts.

The two diferent unrelated projects in /p/q/r and /t/u/v are trying to use it.
Here the only meaningful way to import "f" into "e" is by expanding the file
relative "../f/build.xml" relative to the location of project "e".

So I need to be able to write this, in some way. Notice that having or not
having basedir defined is just a redhearing.

Additionally, projects "e" and "f" may internally need to refer to resources
(i.e., files) located as part of this library, hence I need to have a way
to access the local basedir inside this files.

Jose Alberto

> -----Original Message-----
> From: Stefan Bodewig []
> Sent: 25 July 2003 15:20
> To:
> Subject: Re: ant 1.5.4 : Import
> On Fri, 25 Jul 2003, Conor MacNeill <>
> wrote:
> > Sure. Let me push the C/C++ analogy a little further.
> Leaving this analogy aside ...
> In the particular case you've mentioned (checkstyle.xml using
> build.xml) I'm absolutely with Ken, farm out the common stuff and
> import it from both.  Use composition instead of inheritance.
> > The analogy with Ant breaks when we talk about target overriding
> > which will be a useful usecase.
> Yes, here we are talking about <import> as a method of inheritance, so
> we are using the same task for two different concepts.  Maybe this is
> the cause of confusion and should be amended by either using two
> different tasks or an attribute?  It almost seems as if you'd want
> different basedir semantics depending on which concept we are talking
> about.
> I'm not really sure, which semantics we want to use, but if the
> basedir of the importing file always wins, I fail to see how I can do
> an import in an imported file.  If A imports B and B imports C, how
> does B address C if all relative paths depend on A's basedir, that B
> cannot even pretend to know about?
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message