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 21:06:40 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.
> There are few ( property, taskdef ). And it is proposed and it seems
> many agree on allowing all of them ( just like it was in ant 1.0 ).
> The current version of ProjectHelperImpl2 does allow them ( based on
> Stefan's patch on the main branch ), and so you can use top-level
> tasks now in 1.5, just like import :-)
> I like having top-level tasks, I find it more convenient and clean - 
> and since it doesn't inhibit your use case or preference 
> I don't understand the oposition.

And I don't understand yours.

Having these tasks top-level or having them in an init tag... what's the 

With an init tag you are more consistent with the init-finally pair, and 
don't have the understandment problems I already talked you about.

We are going in circles, you keep saying that top level tasks are 
already here, I say they are not.
And they confuse users.

>>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...
> No - I do rewriting only for the duplicated targets. 
> The one in the 'main' build file will keep the name. All other
> overriden targets will get a name based on the project name. 

Which is confusing to users.

> If you accept the removal of super.super, then it would be
> trivial to take the first overriden target and name it 'super.' 
> instead of using the name - but I feel it's much cleaner to use
> the name of the project ( i.e. what you use in <project name='' >),
> it's more explicit.
> For tasks that are not overriden - the original name remains.

Too confusing.
You are automatically overriding a method and can refer to other 
imported versions with buildfile:target...

>><include file="..."> includes one buildfile in another as-is, like xml 
> Using XSL semantics ( that duplicated targets in included files will be 
> ignored ). 
> +1
>>It should be able to rewrite names to prefix-targetname is specified as 
>><include prefix="prefix-" file="...">
> I don't think it's needed - let's make small steps and see how people
> use it and not add complexity until we are sure it is needed.

It's already needed.
If we make libraries out of imported stuff, there will be massive name 
clashes if we don't do this.

>><project name="" extends="buildfietoextend">
> Same comment here - I think 'extend' on a document is very confusing.
> I've seen a lot of ugliness and complexity even in java, with overuse
>  of extend creating nightmares.
> XSLT just defines import and include - why would ant need more ?

Because you hinted it ;-)

We can have an '<extend>' task - and require that each build
extends at most one file, then what you say makes sense.
I think 'extend' would be very tricky and I doubt its usefullness,
but if you really need it, it can be added - at least as an
external task.

You correctly said that multiple imports of the same target is 
confusing, so I proposed that overriding can be done only from targets 
of one buildfile, for cleanness.

BAsically it's like making only one import possible and many includes.

> As I said, I think we must be open - if you really need this we can
> add hooks to allow this to be implemented using 'meta tasks'. I 
> will vote -0 on it, at least for 1.6.

Why? It's based on your hints.

>>What do you think?
>>Does this make sense?
> I don't think I'll use this, but if you really need it - I'm -0 :-)
> I would do it as a task ( <extend> ) - and the hooks that are needed.

No, you don't get what I mean.

Ok, let's try again :-|

<include> includes like xml entities.
sometimes there are name clashes but you still want to reuse the buildfile.
So you import adding prefixes to the properties-targets.

This is to make it possible to call targets, but it makes it cumbersome 
to hook into a predefined build dependency tree.
To do it, you need to override targets.

For this, you <import> a buildfile, and have included the new targets 
and overridden the already present ones.
You can access the importes target via <target 
name="imported.thetarget"> (was super.thetarget or file:target)

What happens when you import more files?
It's a mess, like in XSLT and in multiple inheritance.

So we make only one import available.

If you need more, you can include different buildfiles in one, and 
import that.

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