ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Problems with <import>
Date Sat, 20 Jul 2002 18:27:04 GMT wrote:
> On Sat, 20 Jul 2002, Nicola Ken Barozzi wrote:
>>I said "deprecate", not "remove".
> And why do you think 'deprecating' something that many people 
> like and use is ok ? 

Eh? I'm not aware that any top-level task can be run in Ant 1.5.

>>>I see no problem with adding a 'destroy' tag - as new functionality.
>>Good :-)
>>>For 'init' - there is already a way to do what you want.
>>In 1.5? I can run *any* top-level task?
> As I repeted several times, all I'm doing at the moment will 
> work with 1.5 if you install ant-sax2.jar in lib. 
> I'll be proposed for ant1.6 and the main branch - but I want
> to be able to use it and to get feedback from  users - 
> and not many people are using the main branch.

Sure. But I don't see how this replies to the above point...

> BTW, your 'destroy' and 'init' will be reasonably easy to 
> add ( as 'special' tasks like import, implementing TaskContainer
> and using a hook to detect the end ).


>>>I'm more confused here - extend and import are very different
>>>things. I don't mind an 'extend' ( especially if you can extend
>>>only one class ), but for 'import' you may have multiple
>>>imports - and most people would be confused if import would
>>>behave as extend ( I am ).
>>Well, XSL works like this.
>>With import, you don't extend a project, but override targets/templates.
>>In Java you cannot without extending the class, please look at the XSL 
>>spec for <include> and <import> to understand what I mean.
> I did - in XSL the 'main' class, doing the import/include, 
> has priority.
> If you have multiple imports you can call the overriden targets - but
> calling them super.super.super with the number of super depending on
> how many imports were made before is inpractical.

I guess there is a misunderstanding.
I have already said this in other mails: super.super.* is really not an 
issue, since I just proposed it for multiple "nested" imports and is not 
really needed.

>>>>But the imported file can import and override the same target from a
>>>>third file...
>>>And you can import 2 files defining the same target.
>>>Which will be 'super' in this case ?
>>The firt one, as per XSL spec on imports.
> And what about the second import,


> or the one imported from the first
> import ? Which one will be 'super.super' ?

this one.

But I'm starting to think it's not needed.

> Using XSLT as guide, it'll be the one imported from the first import,
> and the second import from main will be 'super.super.super'.


> If the first imported build will change and no longer has an import - then
> the second import from main will become super.super.
> Doesn't seem very clean.

Well, the way you put it it's really a mess.
Just the fact that you had problems in understanding what I was trying 
to explain says even more.

> My proposal was IMHO simpler: use the project name to qualify.
>>>Mixing 'import' with 'extend' is very dangerous.
>>XSL spec, that's what I follow.
> That doesn't mention 'super' and is not using and 'extend' semantic.
> It's the 'super.super' naming I have a problem with.

NP then, it's not needed :-)

>>Say I have a master buildfile, that does all I need, *except* that I
>>want to add a task at the end of a target it uses.
>>I need "extend", or rewrite all targets that call the imported ones,
>>which is a PITA.
> What I'm proposing is allowing you do do that, except that instead
> of using super. constructs you need to call the target using the
> name of the master buildfile . target.

What users lament is that if they "extend" a buildfile they don't want 
to write

  ant extendedbuild:compile

but just

  ant compile

If you do compulsory rewriting of the names this is what happens...


What about this, based also on your suggestions:

<include file="..."> includes one buildfile in another as-is, like xml 
It should be able to rewrite names to prefix-targetname is specified as 
<include prefix="prefix-" file="...">

Then the extension:

<project name="" extends="buildfietoextend">

This would work as import now does, but without the multiple inheritance 
that is giving us problems in the definition and usage.

Multiple inheritance can thus simply be done by making a buildfile that 
includes many, and extending that.

When extending, targets that are redefined can call the parent target 
via super.
Allowing calling super.super is not something I see important at all, we 
can ditch that easily.

What do you think?
Does this make sense?

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