ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: override
Date Fri, 01 Aug 2003 10:27:30 GMT
On Fri, 1 Aug 2003 07:40 pm, Jose Alberto Fernandez wrote:
> OK, lets get on the nitty gritty of the matter. :-)
> What do you mean by unrelated imports? If they are unrelated why do you
> need to import them toghether? 

They may be unrelated because they are written by different people. 

I will give an example. Let's say one person distributes a build fragment, a 
template really, for building a Java project. Someone else distributes a 
fragment to do documentation generation. In both cases I want to use the bulk 
of the template as is but I need to override some of the steps. In the java 
generation fragment I wish to add an xdoclet step before the compile step 
whereas in the documetation generation I have some funky logo processing that 
needs to be inserted into the document generation workflow.

So it is this overriding that prevents me from using straight <ant>. The 
authors of the fragments can't know my special requirements but that is no 
problem as I can override some individual steps. The authors may have even 
inserted empty targets to make overriding easy - classic template method 

Unfortunately the authors of the two build fragments don't know of the 
existence of each other and used the same target names in their fragments 
whether it is a simple "init", "compile", "clean" or any of the other very 
common names you find in builds.

> Why don't you use <ant/> to call between the
> unrelated targets? In other words, the now famous example of "bad"
> crosstalk, I could argue is due to bad usage of the <import/> feature. 

You could argue that but you'd be wrong :-)

> The
> build should not have imported files A and B, but just <ant/> them. You
> should have gotten the desired effect.

No override - back to copy, paste and hack. I lose all the benefits.

> On the other hand, if you have to import them, then it is because they have
> to share something or one defines some target for the other, or something.

I disagree. Importing them into a common build does not imply they have 
something in common other than they are both fragments I wish to use in my 
build process. If you want them to interact you should achieve that 
*explicitly* by operations in the importing build file not by some implicit 
coincidence of names.

> If that is the case, then you are crosstalking. And then the whole argument
> changes. You would have to add something to the language to be able to say:
> for this target I want crosstalk, but for that other I do not.
> I think this will lead to spagguetti incomprenhensible buildfiles when
> things go on large scale.

I disagree. What will be spaghetti will be trying to determine the subtle 
failures that come about because of unintended interactions. Not only that, 
there will be no alternative but to alter the fragments, defeating their 
purpose. Every fragment author will need to know about every other fragment 
author's naming scheme. It is this that will not scale to a large system - a 
system where you can reuse build fragments written by other people.


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

View raw message