ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: override
Date Sat, 09 Aug 2003 13:45:31 GMT
Costin Manolache wrote:
> IMHO ant should try to be a bit easier to use than XSLT.

I was playing with some examples to capture the use cases
which have been discussed for include and import with a view
to getting a/some simple models straight in my head.
I am attempting in part to explain the use cases and capture
how parts of it are currently working/proposed and in part
to try to come up with a suggestion for an improved way to
handle the various cases.

I don't think I have quite got it yet (there are some big
gaps in my knowledge of some 1.6 aspects of ant!) but the
examples have got me further than where I was before.
Perhaps some of the gurus can point me in the right
direction and help me understand if I am on the right track.

In particular, I am unsure about how to deal with top-level
tasks. I have been thinking about properties, path references
and fileset references etc. and normal targets. I haven't
thought about antlib namespaces either.

First off, two small sample files to be "reused" later.
Each one has a couple of properties, a couple of path
references (I assume filesets and other types would
be similar) and a couple of targets.


<?xml version="1.0"?>
<project name="common1" default="all" basedir=".">
     <property name="prop1" value="prop1"/>
     <property name="propX" value="propX"/>
     <path id="path1">
         <pathelement location="path1"/>
     <path id="pathX">
         <pathelement location="pathX"/>
     <target name="target1">
         <echo message="target1"/>
     <target name="targetX" depends="target1">
         <echo message="targetX"/>


<?xml version="1.0"?>
<project name="common2" default="all" basedir=".">
     <property name="prop2" value="prop2"/>
     <property name="propX" value="propX"/>
     <path id="path2">
         <pathelement location="path2"/>
     <path id="pathX">
         <pathelement location="pathX"/>
     <target name="target2">
         <echo message="target2"/>
     <target name="targetX" depends="target2">
         <echo message="targetX"/>

Now for examples of attempts to "reuse".


<?xml version="1.0"?>
<project name="main1" default="all" basedir=".">
     <include url="common1.xml"/>
     <include url="common2.xml"/>
     <property name="prop3" value="${prop2} and ${propX}"/>
     <path id="path3">
         <pathelement location="path3"/>
         <path refid="path2"/>
         <path refid="pathX"/>
     <target name="target3" depends="targetX">
         <echo message="target3"/>

For <include> the conceptual model is one of textual inclusion
(or XML entity inclusion if you are that way inclined).
The ant way states (at least for properties) that whoever sets
things first "wins".  I would argue that would be the simplest
model for everything else too (but there has been some talk of
failing the build if nameclashes occur). I would suggest that
whoever is first wins could apply to path references, targets etc.
Depending on my settings I will get a warning and arguably ant
could be run in a "strict" mode which could fail if a property,
path, target was adjusted later.  The implication of this is
that even within the one file you could (though never recommended)
have two targets with the same name - the second would be ignored.
So, for main1 above, running target3 will indirectly cause the
dependency for target1 to be checked - and target2 would be checked
if I reversed the order of the includes.


<?xml version="1.0"?>
<project name="main2" default="all" basedir=".">
     <antref id="prefix1" url="common1.xml"/>
     <antref id="prefix2" url="common2.xml"/>
     <property name="prop3a" refid="prefix1.propX"/>
     <property name="prop3b" refid="prefix2.propX"/>
     <path id="path3">
         <path refid="prefix1.pathX"/>
         <path refid="prefix2.pathX"/>
     <target name="targetX" depends="pre1.target1,pre2.target2">
         <echo message="prestep"/>
         <targetref id="prefix1.targetX"/>
         <echo message="middle"/>
         <targetref id="prefix2.targetX"/>
         <echo message="post"/>
     <target name="target3" depends="targetX">
         <echo message="target3"/>

I have seen some of the import, super, override discussions
but can't see an easy conceptual model following ant's
similar but not exactly equivalent notion of inheritance.
So, what I want to achieve is the equivalent of Java's
delegation trick/pattern used to mimic multiple inheritance.
In Java I wouldn't use inheritance at all but would instead
have two instance variables (the delegates) and I would
pass any method calls on to the appropriate delegate.

This is where things aren't clear to me. In the example
I have used two antref tags.  I am trying to avoid the
nameclash issue altogether - conceptually I either have
some new targets but only full qualified and perhaps not
visible or I may need "target references" to some targets.
Now I can declare my own targets and refer to the original
targets in some fashion either by their fully-qualified names
or using the target reference. I have used a pseudo task
called targetref - kind of like super which has been discussed
before but perhaps I could use (an extended) antcall with a refid?

Any suggestions? Does this help anyone?

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

View raw message