ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: <import> enhancement, it's done, but do you like how it works?
Date Thu, 11 Jul 2002 13:45:23 GMT
 --- Nicola Ken Barozzi <> wrote:
> wrote:
> > Nicola Ken Barozzi <> wrote on
> 07/11/2002 05:48:41 PM:
>  >
> >> wrote:
>  >>
> >>>Is super.mytarget a 'special' keyword? Given that
> you're 'redefining' 
> >>> that 
> >>>target (mytarget), what does antcalling it do?
> This is confusing IMHO 
> >>> for an end user.
> >>
> >>Hmmm...
> >>It works like in java.
> > 
> > Well java methods don't have dependencies..... and
> this will break 
> > compatibility with all targets that are defined as
> 'super.XXXX'.
> Hmmm...

I see no reason why you need to consider "super" as
special, from the point of view of the ANT engine. The
implementation just needs to do a syntactic rewrite.

You ask about backward compatibility. I see no
compatibility issue at all. If you have targets called
"supper.XXXXX" they are just there.

If you have "super.XXXX" and "XXXX" there is no issue

If you import such a buildfile into another AND
redefine "XXXX", then the rewriting rule will renamed
the original "XXXX" to "super.XXXX" which should cause
a parsing error since you have two targets with the
same name (just as it complains today). 

Is this a backward compatibility issue? NO. In this
situation you are modifying the build, directly or
indirectly. Backward compatibility only means that old
buildfiles have to keep on running as intended.
It does not mean that I can start using anything new
and not have to change something.

Actually declaring targets "XXXX" and "super.XXXX" on
the same file could be considered a hacky way to
forbid overiding of "XXXX" on any imports.

> >>super.  is a special prefix.
> >>If I redefine mycooltarget two times I can call
> the first version via 
> >>super.super.mycooltarget , and the second version
> super.mycooltarget .

This actually I do not like. I do not mind that it is
an unintended consequence, but I do not think it
should be promoted.

> >>
> >>Any suggestions on how it can be made better?
> > 
> > Don't use antcall and target..... add a new tag to
> call the overidden 
> > one.....lots of other possibilities...??
> Ok then how about:

All the alternatives below require not only providing
a new project-helper but also modifying ANTs engine.
Which means it cannot be used as an add-on to ANT1.5
and most probably would only work as part of ANT2.

I still think there is room for doing it syntacticly
(i.e., in ProjectHelper). It may not be as perfect as
it could, but I think it can be done.

See ideas below.

> (a)
>   <target name="mytarget" >
>     <dostuff1/>
>     <antcall target="mytarget" super="1"/>
>     <dostuff2/>
>   </target>
> (b)
>   <target name="mytarget" >
>     <dostuff1/>
>     <super level="1"/> <!-- level is optional -->
>     <dostuff2/>
>   </target>
> (c)
>   <target name="mytarget" allowoverride="true" >
>     <dostuff1/>
>     <super target="mytarget"/>
>     <dostuff2/>
>   </target>
> (d)
>   <target name="mytarget" >
>     <dostuff1/>
>     <antcall target="mytarget"
> select="this|super|super.super|..."/>
>     <dostuff2/>
>   </target>
> (e)
>    combinations of the above.

One pattern you guys forgot is:

  <target name="mytarget" depends="super.mytarget">

which adds more things to do on the target. And:

  <target name="mytarget" 

  <target name="mytarget-local">

which executes super after. Both will mix the
dependency trees. This I think uses more of the power
of ANT than just limiting ourselves to <antcall/>
of course <antcall/> should be supported.

With respect to the syntax of "super" what I would
probably do instead of denoting it just as the string
"super.XXXX" I would use some different notation,
for example:

  <target name="mytarget" 

now, I doubt anybody has a property called like that.
So I think the backward compatibility issue is
negligeable. The advantage I see with this notation is
that it allows ProjectHelper to do more powerfull
rewriting. In the following situation, for example:

File: ${basedir}/includes/A.xml
  <target name="mytarget" depends="a,b,c">

File: ${basedir}/build.xml
  <import file="includes/A.xml"/>
  <target name="mytarget" 

The rewriting done by ProjectHelper will look like:

  <target name="include/A.xml::mytarget" 

  <target name="mytarget" 

Notice that all the rewriting can be computed
statically, so there is no issue here.

This particular mangling rule for the overriden
targets has the advantage that when we see the
execution of the build we will be able to identify
which version of the target is under execution at any
time. Notice that everthing stays syntactic with no
changes on any of the tasks, in principle.

And as with my comments above, if after rewriting
something clash, then the files are not upward
compatible, which is OK.


Jose Alberto

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message