On 2008-11-13, Matt Benson <[EMAIL PROTECTED]> wrote: > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> On 2008-11-11, Matt Benson <[EMAIL PROTECTED]> >> wrote: >>> Personally I would prefer supporting arbitrary attributes on >>> targets. >>> This would be less specific to EasyAnt and could have mileage for >>> other Ant extensions. Do you envision that we replace Target with UnknownElement and friends or are you "just" thinking of a Property-Set that can be associated with a target? EasyAnt would still need a custom ProjectHelper to make sense of the additional attributes, I don't see this as major a problem, though. >> I read this as "I don't want the feature in core but provide hooks >> to make live easier for EasyAnt", right? > Pretty much, yeah, unless someone can make me see how "phases" (by > whatever nomenclature) are relevant to basic Ant-fu. :) OK, I'll try. Take a look at the build file "infrastructure" (big word and it will become worse ;-) for our antlibs, in particular http://svn.apache.org/repos/asf/ant/antlibs/common/trunk/build.xml It contains a number of empty targets with names like "ready-to-compile" which are in there as extension points. If an antlib needs to do something in addition to what ready-to-compile does, it overrides the target with one of its own (which again depends on the imported one). This is a pattern you'll often find in build files designed for re-use. I think Steve uses this in Smartfrog and I know I've used it at work myself. \begin{overstatement} "phases" turn this design pattern into a language feature. \end{overstatement} Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
