ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariusz Nowostawski <>
Subject Re: [PROPOSAL] Optional Tasks
Date Mon, 11 Dec 2000 13:08:53 GMT
On Mon, 11 Dec 2000, James Duncan Davidson wrote:
> 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">
>   ...
> </ejb>
> 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.

I want to go there as well. But, I would rather see it like this: the
abstract class plug in as task, with all the common attributes different
implementations share, and then a particular implementation plug in its
additional funcionality. 

<ejb name1="value1" name2="value2">
   <weblogic name3="value3" />

name1 and name2 are common parameters for all possible ejb tasks, and
name3 is weblogic specific.

Each abstract task has the default implementation, thus the user does not
need to specify it, but for all the others, nested tag needs to be
used. for parser generators it could be that default is metamata:

<javacc grammar="mygrammar" outputdirectory="src" /> (default metamata)
<javacc grammar="mygrammar" outputdirectory="src">
   <antlr/>  (possibly with antlr specific parameters)

Mapping between nested tags and java classes is done via property files,
or whatever metadata format is being used for tasks. The point is, that
abstract task implementation takes care of all the standard stuff, and
passes it to the implementation, which then takes care of implementation
specific stuff, and does the job. The implementation is pluggable via the 
nested element.

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

Here I would go for:

<javac ... /> (default, i.e. modern, if not available, classic)

<javac .... > (all generic parameters)
   <jikes pedantic="on" >  (all jikes specific options)

<javac ...>
  <mjavac > (all metamata specific stuff here)

Who has proposed that before? I am sure I saw it being proposed, but it
never made its way to codebase, don't remember why?


View raw message