ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Rettig <>
Subject Re: Importing and caching build files from a URL
Date Tue, 29 Nov 2005 16:38:31 GMT
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.


<urlimport root="" file="

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.

   <import file="compile.xml"/>

When compile.xml is imported, a call will be made to the root (") to resolve compile.xml. This makes the
remote import transparent.

This would not be difficult to implement and would not break existing


On 11/29/05, Dominique Devienne <> wrote:
> On 11/29/05, <>
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message