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 files: /a/b/c/d/e/build.xml: <project name="e"> <import file="../f/build.xml"/> </project> /a/b/c/d/f/build.xml: <project name="f"> <echo>Here is F!</echo> </project> /p/q/r/build.xml: <project name="r"> <import file="/a/b/c/d/e/build.xml"/> </project> /t/u/v/build.xml: <project name="v"> <import file="/a/b/c/d/e/build.xml"/> </project> 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 [mailto:[EMAIL PROTECTED] > Sent: 25 July 2003 15:20 > To: [EMAIL PROTECTED] > Subject: Re: ant 1.5.4 : Import > > > On Fri, 25 Jul 2003, Conor MacNeill <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
