Re: Mixed-media Tasks was Extension to Manifest task?

[Matt Benson <gu...@yahoo.com>]

--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 3 Mar 2004, Craig Berry
> <Cr...@portblue.com> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org