ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: override
Date Thu, 07 Aug 2003 12:50:30 GMT

Costin Manolache wrote, On 07/08/2003 4.43:

> Thanks for the overview, Nicola !
>>Just to get you up to speed, the current issue is about multiple
>>inheritance, and how the current system allows cross-import (unwanted?)
>>side-effects, as Conor has brilliantly shown.
> What I'm not sure I understand is what import has to do with multiple
> inheritance :-)

Because we can import two targets with the same name from different 
files. Making them work together is conceptually similar.

> Most of the problems with cross-import and side effects could be resolved by
> just using qualified names ( or namespaces ) - like java does to
> disambiguate imports. 

Really? ;-P

>>A brief recap of decisions taken IIUC:
>>- add an attribute to project: @importable=true, false, only
> I hope it is not required, and if it is missing it defaults to true.

Sorry, I was not clear. Should have written:

- add an optional attribute to project: @importable=true, false, only
   if missing, it works as importable=@true but issues a warning
   (warning level to be decided)

>>- add possibility of prefix in import declaration
>>     <import file="xxx" prefix="xxy"/>
> This would work as a "qualified name" ? 

I think basically yes, but

> What's the syntax for the 
> prefixed targets/properties ? 



> Any consideration on using XML namespaces 
> for this ?

Not in this particular discussion. They had been proposed in earlier 
iterations. IMO it would make sense if we fully encapsulate imported 
buildfiles, which is not the case with import.

>>- all paths are resolved resolved to the importing file basedir
> The top-level importing file, or the imediate parent ?

Per transitive property, to top-level importing file.

>>- keep projectname.ant.file property for relative path resolutions
> Good.
>>- add <include/> task, like entity includes
>>- add <override-target/> task to override targets
> Is this "override-target" a substitute for <extends> and OO use of 
> ant ( i.e. a buildfile == class, target==method ) ? 

In a sense yes, but not quite. Import does not fully encapsulate the 
calling buildfile. @see XSLT include and import for a more similar concept.

> If so, wouldn't be more intuitive to just use the real concept - i.e.
> extends and inheritance ?


> I know python has a very nice namespacing mechanism where you can replace
> or add methods dynamically to an object, but I don't know if this is
> desirable for ant. 

KISS. Personally I don't need that (yet) I guess.

>>Threads about import (in order):
>>    1 - ImportTask ant 1.6
>>    2 - ant 1.5.4 : Import
>>    3 - override
>> From thread 2 I wrote:
>>multi-import(import a,b)
>>   target test depends=a.test, b.test
>>   target critical
>>   target test depends=critical
>>   target critical
>>   target test depends=critical
>>Here "critical" means a.critical to a and b.critical to b, but since
>>they reference a generic "critical", they get the only one that remains
>>after being redefined. The problem is that I did not redefine it in the
>>main buildfile!
> Can this be resolved by making all targets qualified after the build file is
> read ? 

This is what Conor seems to propose IIUC, and what others are not keen 
on, and instead talk more about the xslt-type import.

Just remember that we are not talking about renaming properties, or 
resolving basedirs, so it's not full encapsulation, but just 

I have not yet made up my mind, but it seems that ATM there is a reason 
favor some kind of "namespacing" because I see more harm than good in 
side-effects that come out of not doing it. How this can still solve my 
usecase is yet to be seen.

> That would mean ant will see:
>   top:
>     target top.test depends=a.test, b.test
>   a
>     target a.critical
>     target a.test depdends a.critical
>   b
>     target b.critical 
>     target b.test depends=b.critical
> After reading any build.xml file, ant will just look at all targets and 
> add the project name as a prefix if they don't have one already ( we just
> need to agree on the separator syntax ).

Or simply use the proposed prefix when importing.

> When you look at a build.xml, all targets that don't have prefix are
> resolved to the current build file - it's pretty easy to understand. 
> That mean you won't be able to use import for crazy overrding of 
> some targets from one file with targets from other file - but if there is a
> real need for that i have no problem with a python-like mechanism where 
> you can add/replace methods in an object at runtime. As long as it's 
> not disguised as <import> :-)

Well, IMHO I personally don't see a real, strong, compelling reason to 
have targets have crosstalk between themselves, but I do have an equally 
strong need to import dependencies.

As I have outlined before, imagine I import a file that has a compile 
and test targets.

  target compile
  target test depends=compile

I want to be able to do "ant compile" and have it compile. Thus the 
compile target should not be renamed.

Then when I want to insert a pre-condition to the compile target, I want 
to be able to redefine the compile target.
Reusing it in a differently-renamed target is not ok, as when I call 
"test", it will not have a dependency to the new version of the target.

  target compile
  target newcompile (call:prestuff, compile, poststuff)
  target test depends=compile

If I call newcompile, it works but calling test will not call the new 
one, thus making it impossible for me to *decorate* the compile target, 
thus specializing the template.

So I should have:
  target compile -> original compile
  override-target compile (call:prestuff, original.compile, poststuff)
  target test depends=compile

Till I import *one* compile target instance, all is well. As soon as I 
have more of them, I start having problems.

The question is: after a multiple import, which compile target becomes 
the "default" one, ie the one without renaming?

Second question: how do we deal with the fact that targets that are not 
even used have crosstalk between themselves?

And most of all: how to solve the last two points while keeping it 
possible for me to retain the use-cases?

As you see, for this usecase, <include> is not strong enough, as I 
cannot override, and complete namespacing prevents me from overriding 
the dependency chain.

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