ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Re: [PROPOSAL] Optional Tasks
Date Mon, 11 Dec 2000 09:28:06 GMT
On 12/10/00 5:02 PM, "Conor MacNeill" <> wrote:

> One thing which I would like some thought on is the situation where we have
> a task which defines an "interface" and for which there may be many
> implementations. A current example would be the <ejbjar> task which really
> defines an interface into which specific EJB deployment tools can be plugged
> in (as nested elements).

A second level interface -- i.e. Have a set of abstract classes that plug in
as Tasks, but they themselves have impls that are specific.

IOW, you probably want something like

<ejb impl="" name1="val1" name2="val2">

Where the ejb task is a shell that looks up the impl specified and then sets
things on that. I think that would be the cleanest way to get to where you
want to go.

> Another candidate is the <javac> task itself. The current mess of supporting
> many compiler variations is not really nice. I would like to see a mechanism
> where different compilers could be plugged in. In fact such a system would
> allow the Jikes implementation to be moved out of the core and into the
> Jikes project.


<javac [impl="org.apache.ant.javac.JavacImpl"] .... ></java>

Where the implicit is the Ant native version that just uses the JDK (so you
wouldn't ever do the above), but you could set impl="jikes.compilerImpl" and
it would defer things out to that impl.

> In summary, I think there are cases where it would be nice to define a
> common "interface" for a task and allow different implementations for this
> task. I don't want to lose sight of that unified approach because the
> optional tasks are scattered over the net.

Right. Though of course that interface will be unique per task type. Ie, the
javac and ejb examples above would have different interfaces.

James Duncan Davidson                              
                                                                  !try; do()

View raw message