ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: ant 1.5.4 : Import
Date Tue, 29 Jul 2003 11:47:23 GMT

Stefan Bodewig wrote, On 29/07/2003 12.59:

> If you want to simplify things, why not go even further?
> On Tue, 29 Jul 2003, Conor MacNeill <>
> wrote:
>>1. import with optional name. The name is to be used in the renaming
>>of targets.
> I'd like to think about removing target renaming completely.  What
> exactly is the use-case for this?  I've come up with a vague idea, but
> it would help tremendously what people do want this feature for.

I thought I had already answered this?

Anyway, the need is that I have to be able to override a target I import.

For example, let's say I have a compile target I want to import, and I 
want to make it additionally call the "pre" target before and the "post" 
target after. This is a very common usecase that can make me reuse 
targets with minor adjustments case per case.

So, let's say that there is no renaming. To use the imported compile 
target I will have to make my "mycompile" target.

  <import file="commontargets.xml"/>

  <target name="mycompile" depends="pre, compile, post"/>

  <target name="pre">

  <target name="post">

Now all seems ok, just a minor issue that I cannot use "compile" but 
have to change name...

Then I want to run the test target that is in the imported buildfile.

Wait a sec, the test target in the imported buildfile is:

  <target name="test" depends="compile">

But it won't work, as I need to call "pre" to be able to launch a compile!

There is no way out, I'm not able anymore to use an imported target.

In case of renaming, I can do:

  <import file="commontargets.xml"/>

  <target name="compile" depends="pre, original.compile, post"/>

  <target name="pre">

  <target name="post">

and test will work.

What renaming does is give me the possibility of decorating the imported 
targets, and effectively importing the dependency graph, not only the 
single targets.

This is a major feature of import.

>>2. Define a single property ant.import.file which is resolved at
>>import time to the import location. All other properties are nt
> Why does the imported/included file need to know its name, after we've
> limited it to not access resources relative to its own basedir as in

It *has* to be able to access resources relative to it's position, else 
for most purposes it's useless.

The problem comes with the concept of "basedir", as in normal buildfiles 
it references the path WRT which all paths are resolved. Here they are 
*not* resolved automatically, but the author can use to do it in a 
similar way by using the and file position.

It's the automaticity of this resolving that is the problem, and 
"basedir" is normally associated with it.

>>4. All normal Ant operations (i.e. not imports) are resolved to the
>>basedir of the outer project. There is no access to other basedirs.

If the above two features were missing, it would be almost of no use. 
And yes, in that case it would have to be called imclude.

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