ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Alias names for imported targets
Date Sat, 05 Jun 2004 19:08:10 GMT
Dominique Devienne wrote:

>>From: Nicola Ken Barozzi []
>>Jose Alberto Fernandez wrote:
>>>All this restriction in OO inheritance are there to limit
>>>developers capability of writing spaguetti. We still do, but...
>>Import overriding is not about OO inheritance, it's about target
>>dependency injection, which is not quite the same thing.
>>Look, if you import in Java packages that have the same class and then
>>want to use a specific one, you must use fully qualified names. Why
>>can't I in Ant? What does this have to do with inheritance?
>>Ant import is *different* from other mechanisms, so analogies can help
>>but are not the same thing.
> Hmmm... I've recently read quite a bit about dependency injection
> and IoC on the Spring, HiveMind, and MartinFowler sites, and I don't
> think Ant's import/target override mechanism has anything to do with
> it. I think you must be meaning something else that what this term
> has recently been used to describe...

:-)) Yes, I mean something different, and it's funny to see this 

What I was trying to say is that importing targets one gets new target 
dependencies, not only new targets.

Namespaced Antlibs do not do this: what I get are extra tasks, which do 
not do things automatically.

When importing instead I get targets that can automatically get wired to 
  others, thus getting called in the existing dependency resolution.

> The closest cousin to Ant I can think of is XSL. 

Again, another analogy! :-)

> XSL has a proper
> include/import model, and also the Java equivalent to super., where
> an overriding matching template can explicitly invoke the overridden
> template. But that's it! You can never otherwise distinguish what
> comes from the main stylesheet from what comes from included or imported
> stylesheets, directly or not. 

It's still different...

> Having this access just break encapsulation
> and would lead to spaguetti buildfiles, as Jose Alberto puts it.

I see that you two are particularly firm in this, and to be honest I'm 
just trying to play the other side for the sake of discussion. On the 
pther hand, I am not convinced by your reasoning, as it's subjective, 
not objective (mine is too).

Let me try to take a step back and ask you a question: what is <import> for?

Originally it was to do all sort of things for extending builds, but 
then some very clever coder came up with macrodef and typedef, and most 
of the reasons of import fell.

If I want a particular target to be called, I should not want a target, 
but a macrodef. When <import> was first put in there, some really wanted 
it to work like a sort of macrodef, and most, including myself, are 
using it for this purpose.

In *this* case, having the feature discussed here makes sense. In *this* 
case, using the inheritance analogy does *not* make sense. IMHO this is 
the reason why we are not understanding wach other, as we think of 
different use cases.

Could it be that we should simply hint that in this case one should use 
a macrodef instead of a target? I start to think that this 'feature' 
should not be allowed because of this.

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