I don't disagree with your scenario in the sense that it would break, but I disagree that it's either a good usage of import or desirable.
I (strongly again ;) believe that imported build files should be designed to be imported, and never used without being imported. I would even be favorable (but I might be the only one) to add an attribute to <project> that was required the be import-able, and would render that build non-usable directly. This way, you eliminate any possible confusion. --DD > -----Original Message----- > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2003 10:23 AM > To: Ant Developers List > Subject: Re: ant 1.5.4 : Import > > > I'm interested to hear about use bases that would refute my argument on > the > > other hand, to see what I missed. Thanks, --DD > > > > Say I have build B importing C and I'm using B quite happily. > > Then one day, I create A to import B and the import in B of C no longer > works > because B had a basedir setting. That would surprise me. > > The above scenario assumes that we are taking basedir into account in the > B->C > case, which is not what option (2) is about. But option(2) makes > resolution > of import names not follow the same rules as every other Ant task (i.e. > taking into account project basedir). > > I guess I can live with (2). Basedirs are not that common anyway, and > having > import outside that framework is OK. > > Conor --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
