This is indeed a valid use of knowledge of where an imported file was imported from.
I still think (strongly) that the basedir of any imported file should be ignored (with a warning if it's something else than ".", the default), and always use the one of the top-level build. To allow the use-case presented by Stefan, and disambiguate unequivocally what is being used, a new magic attribute should used to locate resources/files relative to the currently imported file. During import, this magic attribute would be resolved/replaced at parse time, so each imported file is fully resolved against is own directory. Finding names is always difficult, but an 'importdir' attribute doesn't sound too bad. --DD > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 10:09 AM > To: [EMAIL PROTECTED] > Subject: Re: ant 1.5.4 : Import > > That is that I can write an importable snippet that doesn't depend on > on its own location by omitting the basedir attribute and setting it > if it does. > > The usecase for the later is something like Centipede's cents (as I > understand them) where a <taskdef> in the imported snippet needs to > specify jars for the classpath - and would do so using relative paths. > For easier installment of the full package, that should be relative to > the imported file IMHO. > > Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
