ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Usage of import
Date Fri, 06 Jun 2003 12:30:27 GMT

Tim Gordon wrote, On 04/06/2003 14.31:
> Right. Well, let's see how far we get on this list, as I'm keen to avoid
> cross-posting...
> To be fair, the import task is heavily flagged as experimental and may not
> even make it into 1.6, which would be a great shame.

Keep in mind that it's *months* that Centipede and all projects using it
are using this task regularly. So it's sorta-experimental but not quite ;-)

> Having done a fair bit with multi-project builds in the last couple of years
> using ANT, the lack of direct support for multiple projects makes resorting
> to heavy use of the ant task. ANT's heavy leaning towards being a
> declarative build system is somewhat violated by usage of the ant task, as a
> lot of the features that are declarative can no longer be used (specifically
> resolving dependencies).
> I like the depends checking against targets in imported ANT files! It's
> great.
> I don't like:
> If we're using the import task to express the dependency of one project on
> another then you'd expect targets in the depended-on project to behave as if
> they'd been invoked directly on that project - import doesn't allow for this
> because relative paths seem to evaluated relative to the importing file.

This is because the import task does *not* express the dependency of one
project on another. It simply uses the other project as a library.

To use it as a dependency we use Centipede or Gump, that are built on
top of Ant.

> If multiple imports ulitmately imply the import of another project twice
> then why the warning? It's definitely going to happen in the future and it
> ought not to be a problem - graphs of dependencies are what it's all about
> here, after all.

Just to let the user know it's happening. Maybe it's ok to drop to DEBUG.

> It's not clear how name conflicts are handled, it would be useful to
> optionally specify some kind of namespace for the imported project so that
> tasks in the imported file were all prefixed with something.

This has been discussed, and it brings some problems that were not
resolved. Remember that imported projects are libraries, not project

> Suggestions
> - Maybe have a pathsrelativeto=importer|imported directive on the import -
> this gives you the option to either

It's a hedeach, as if you make it wrong, the file won't work. Imported
files need to be made for import, no matter what flags you use, as we
have seen after months of experiments in Centipede.

>  - inline another build.xml in place of the import, so that relative paths
> are resolved with respect to the importing ant file's basedir (more of a
> include, than an import)

Things are resolved relative to the main build, as import does work as
an include.

The problem is relative files WRT the imported file, and this was solved
by adding a property for every imported file that keeps the path of it,
so that it can use it to resolve relative files.

>  - Simply state that you depend on a project defined elsewhere and that
> target invoked in the imported file will behave as if you were using that
> file directly.

This is not in the scope of this task. For it, you can simply run
    <ant antfile="xxx" target="xxx"/>

or use Gump or Centipede that use a descriptor to express these
dependencies, fetch jars, etc.

> BTW, I know this could be asking a lot.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message