Stefan Bodewig wrote:

> On Wed, 23 Apr 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 
>> If everything is defined as a component at a low level, then they
>> can be easily introspected to find out what interfaces components
>> implement.
> 
> This breaks down if there is no specific interface for a role - like
> task or data-type.  And also doesn't address things that can be in
> multiple roles.

Interfaces _and_ patterns. ( and in "interface"  I also include extending
some base class like task ).

If it has an execute() method - that method will be called, even 
if you don't extend Task.
It would be nice to have init()/destroy() patterns on the datatypes as 
well. 

What matters at low level are components. 

What matters at high level ( i.e. from a target perspective, or a task
that includes other tasks, or a datatype that uses some roles or conditions
) are the operations that a component supports. Operations can be expressed 
by interfaces, or by patterns.

It may sound a bit to JMX-ish, but this is something that works amazingly 
well. Everything in tomcat is becoming a simple JMX component. JBoss ( which
is even more complex ) operates in terms of mbeans - with
init/start/stop/destroy pattern. If some mbean happens to be a servlet
container and another mbean happens to be an EJB container or just a simple
logger or set some properties - it doesn't matter.

And what's nice is that we don't need to change much in ant to achieve that.
We can say it's almost already available. 



> At least for task I'd expect some strong opposition against an
> interface that marks them up.  Hi Costin ;-)

Of course. There is no need to have a Task interface, or even require Task
to be extended. Ant's strength (IMHO) comes from the lightness of the 
framework. Just add an "execute" method to your java bean and you can 
use it in ant. Very low entry point, no pressure, no strong dependency.

JMX is the best analogy, and it's used with success in things far more
complex than ant. You only have to support certain operations. 

That's not to say I'm against using interfaces to define roles - my 
only problem is to keep the interfaces "informative", not "required".
There is no need to be stricter than JMX - which also uses interfaces,
but supports declarative model ( model mbeans - you just use descriptors,
and any java object ) or direct calls ( dynamic mbeans ).

Costin



Reply via email to