--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Wed, 3 Mar 2004, Craig Berry > <[EMAIL PROTECTED]> wrote: > > > The fit turns out to be rather awkward. > > Doesn't look that bad to me. > ... > > I understand that this operation may be common to > build a Class-Path > attribute for arbitrary manifests, so if we want to > create specific > support for it, my target would be the manifest task > rather than the > ear task as well. >
This whole discussion has put me in mind of Ant 1.7-related concepts... specifically all Tasks living in various antlibs. This discussion has brought to my attention the fact that some changes like this might be more easily/tersely expressed terms of Ant buildfile syntax than Java or other source code. Firstly, if we had a task that implemented DynamicConfigurator and had a classname attribute, it would be possible to say: <(task|anontask) classname="my.package.MyTask" ... /> This is like a non-persistent <taskdef>. A <task> without the <def>, if you will. Does an equivalent exist? Then, if we wanted to add functionality to a task, we could modify its antlib definition into a <macrodef> whose <sequential> first calls the basic Java Task in the above manner, then adds additional processing in Ant terms. This might require less of both coding and testing for new features when those can be atomically divided from the basic Task behavior. Am I out of my mind? -Matt __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
