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