ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: override
Date Fri, 08 Aug 2003 06:04:15 GMT
Jose Alberto Fernandez wrote:

> One of the problems I have with the "rewriting" approach is that target
> names get rewritten y the caller which means that two independent
> importers may decide to use the same prefix and hence you get a clash.
> Namespaces or java-style fully-qualified-names are a property intrinsic
> of the imported file, that is the reason that makes it safe.

That's why I think it's better to not try to be too flexible in allowing
arbitrary rewriting, but do it in a canonical way:
 - after a build.xml is read, all un-qualified names get prefixed with the 
project name and a delimiter ( need some tricks for ant-call, but it's
possible )
 - you can call a target by the local name as long as it is unique,
otherwise you need qualified names.

No overloading, no conflicts, no abiguity.

> Single inheritance (a la Java) requires having syntax that allows for
> extending only once, something like:
>   <project name="q" extends="this/other/build.xml">...</project>
> if you use something like a task to specify the extend then you may write
> multiple inheritance and all these ambiguities appear.
> Could we live with single inheritance and <include/> instead of <import/>?

My point is that <import> is different than "extneds". 

> The escenario is that you have your tipical:
> a
>    target compile depends=precompile
>    target precompile (do-nothing)
> b
>    target precopile (very complex precompile lib)
> build:
>    import (a,b)
> With cross-talk that is all you need to connect the two
> and get the required effect. Without cross-talk you would need to add
> more targets to build:

With qnames there is no crosstalk.

   target a::compile depends a::precompile
   target a::precompile

  target b::precompile

  import a, b
  You can call a::compile ( which will call a::precompile ), etc.

>    target precompile depends=b.precompile
> or
>    override-target compile depends=b.precompile, super.compile

Too complicated IMO. 

All import should do is load some build files and deal with the 
name conflicts in a clear way, without becoming a very hacky solution
that nobody understand - and to be honest I have a lot of trouble 
understanding most of the overriding - even in the simple examples 
on the thread, I can't imagine what will happen when people start using this
with dozens of targets.


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

View raw message