> -----Ursprüngliche Nachricht-----
> Von: Steve Cohen [mailto:[EMAIL PROTECTED]]
> Gesendet am: Freitag, 6. Juni 2003 16:54
> An: [EMAIL PROTECTED]
> Betreff: 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.
>
> SO...
> 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
Nice idea. When I wrote my "library" of ant snippets I used <script> for
executing targets which maybe not exist. With that I could implement a
standard behaviour (do nothing) and "override" that in the buildfile.
Example of my "library":
Jan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
