I've worked with the import task quite a bit, and I believe resolving imports by relativity to the parent file works fine and is intuitive. I import many shared build files from different working directories and all build files resolve as expected. This makes the build files easy to reuse across builds.
The relative imports are an issue since URL's don't map to the current import structure (relative to the build file). A URL has no concept of a 'parent'. My implementation works around this by downloading the URL to a cache dir. Then the downloaded import can be loaded in the usual manner. With URL's, another approach could be to specify the URL root for resolving future imports. i.e. <urlimport root="http://mybuildserver.com/buildfiles"; file=" standard-build.xml"/> This root could then be placed on the import stack for resolving all imports that originate from standard-build.xml. This same approach could be used for jar files, or directory locations. The standard-build.xml would be implemented as you expect. <project> <import file="compile.xml"/> ........ </project> When compile.xml is imported, a call will be made to the root ( http://mybuildserver.com/buildfiles";) to resolve compile.xml. This makes the remote import transparent. This would not be difficult to implement and would not break existing funtionality. Mike On 11/29/05, Dominique Devienne <[EMAIL PROTECTED]> wrote: > > On 11/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > It would fit better into Ant´s future if the existing <import> would > > support <resources> - e.g. <urlresource>s. > > We've had this debate before... > > I'd be all for allowing to <import> resources instead of files, except > for the way <import> was designed to not do things relative to its > parent directory, like HTML and XSL hrefs. I can't see how we could > have a clean "relative" import model like HTML/XSL while retaining BC. > Yes, we could probably import easily a resource of the "first level", > but it would be kludgy at best for this imported build to refer to > other resources in the same jar file for example. > > So really we have to choose between limiting ourself to our current > design for import, or extend it to resources but in such a way that I > feel is unnatural, inconsistent, and a bit of a hack. But maybe I'm > just missing the point somewhere, or my view that import is flawed is > what flawed in fact ;-) --DD > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
