ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: Overridable targets?
Date Fri, 06 Jun 2003 15:13:47 GMT
I can see that that would work, but it seems to be more difficult than
what I am proposing.  You have to make sure that EVERY build file that
includes your generics defines the changeable behavior, and you can't
have a overridable default implemenation in the generic file.  Or am I
missing something.

-----Original Message-----
From: Matt Smith [] 
Sent: Friday, June 06, 2003 10:05 AM
To: Ant Developers List;
Subject: RE: Overridable targets?

I have implemented this in ant 1.5.1 and 1.5.3 and have been using for
multiple projects without issue.  I have cascaded build files throughout
each of my projects, and each build file has a set of common targets
with are included in the project specific buildfiles via the XML ENTITY.

I also allow project to overloaded so that you can include a completely
separate buildfile in a target and use am using it to define project
dependencies in a hierarchical way!

Works Great!


-----Original Message-----
From: Steve Cohen []
Sent: Friday, June 06, 2003 9:54 AM
Subject: Overridable targets?

Here is a radical idea that I'd like to kick around a little.

The prohibition against more than one target of the same name in the
same build script seems logical, but it impedes a form of reuse that I
think would be very handy to use.

If you include one build file within another (using ENTITY inclusion
mechanism) and you want to use all the targets in the included file
except one, which you would like to replace with a slightly different
functionality, and that target is called by another in the INCLUDED
file, you have to go through a lot of annoying stuff using if, unless,
etc. and perform redesigns on your script that render it far less clear
and less readable.  In many ways it feels like a straitjacket.

what if...
targets followed the same rule as properties????

That is, if two targets with the same name are found in one build script
(after inclusions performed), the first is used and the second discarded
(instead of as now, when this throws an error).  Then you could include
your generic bag of generally useful targets, but redefine one "inner"
target differently, to customize a particular build outside of the
generic pattern in some way.

The rule against two targets with the same name is an ant rule, not an
xml rule, so this is in theory doable.  It doesn't seem like it would
break that much because this has never been allowed before, there is no
previous set of semantics working against it against which backward
compatibility must be preserved.

There is probably some reason why this cannot work but I can't think of
it, so I will throw it out to the group for discussion.

Have at it!  Please, though, not too hard. :-)

Steve Cohen
Sr. Software Engineer
Sportvision Inc.

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

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

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

View raw message