Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-Id: <3.0.6.32.20010508230334.00a6a100@mail.alphalink.com.au>
Date: Tue, 08 May 2001 23:03:34 +1000
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: [Vote] Task API 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi,

With the arrival of Ant2 we have an opportunity to make it follow more of
the conventions of other component based systems. If you look at the
conventions followed it many of the Java component specifications many of
them follow the same design patterns. In my discussion I will talk about
servlets as they are the most popular and most widely known component based
system.

If you look closely at the Servlet spec it is a very minimalist
specification. It aims to specify the container-component interface. Later
revisions also added specification for deployment descriptors. 

I would like to follow a similar model in our specification of the Task
API. Doing this would theoretically allow multiple different task
containers to be written. While this may not be something that ever
eventuates this kind of design decouples the container from the components
(aka tasks) and makes it easier for task writers and developpers to write
tasks that don't have spagetti code.

I propose that the task API consist of the following classes interfaces

interface Task {}
interface TaskContext {}
class AbstractTask {}

The task interface would be the minimalist interface and would likely only
have one "work" method - namely execute() - it would also have other
lifecycle methods to specify initialization and passing TaskContext. So any
class that implements Task can be executed by the engine. 

TaskContext is the interface that the Task uses to communicate with its
container. If a task requires some sort of container supplied resource (ie
properties or execution stack or "name" of task or ...) it is accessed via
the TaskContext.

Because implementing the Task interface is trivial there is also a helper
class AbstractTask that implements Task. It also caches TaskContext and
offers helper method to use TaskContext (So instead of going
getTaskContext().getName() you could just go getName()).

The above design is common to many component based systems and should be
familiar for task writers. It also follows many practices that are commonly
recognized as good (AOP and IOC - but you knew I was going to say that 8-O).

So the above are the minimal specification of Task API. In the future I can
see this being expanded to things like Converter/AbstractConverter +
DataType/AbstractDataType. However as we haven't yet discussed some
sensitive issues about this I will delay that to a later vote. 

I also have not specified a deployment descriptor or deployment archive (ie
.tsk file). These things will come in time and need more experimentation
before we can decide what to do.

You can look at the myrmidon proposal in package org.apache.ant.tasklet for
a somewhat older view I had of arrangment. It is mostly similar except a
few things would need to be renamed.

Some issues were highlighted (with respect to these APIs) when I integrated
the mymidon as an embedded component in another system but I will leave
these to later discussions (They are minor and not important at the moment).

BTW: this does not preclude including fileset et al in ant. It would just
be in a different layer - much like using turbine makes using the servlet
API easier, using fileset et al makes using the task API easier.

Thoughts/Votes?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*