ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: antlib
Date Wed, 23 Apr 2003 17:35:44 GMT
Dominique Devienne wrote:

> Let's turn around your question: Tell me of a (string) role (beside the
> special task/type cases) that would not be an interface? What good a bean
> is, if it's not of an expected Java type? What method or field are you
> going to use/call on it?

Any role. Just like you can put any java class with an execute() method 
in a "task" role, or any java bean in a "datatype" role. 

Interfaces are fine - they define a set of methods and contract that a class
must support. But it is perfectly possible to support the contract without
implementing the interface. In JDK1.3+ ( and JMX1.2+) you can use a proxy
that implement the interface - but what really matters is the contract,
not the syntactic detail.

Ant ( and JMX ) have allways had a "loose coupling" aproach. You can write a
lot of tasks without having any dependency on ant. 

> I agree with Costin, all tasks/types become simply beans. You should be
> able to use any one of these beans in any place it's suitable to use it,
> i.e. any time the Java type/role requested is part of the bean's type (in
> the isAssigneableFrom() sense).

I agree with you that "roles" should be associated with an interface.
I don't agree that the components need to actually implement the interface,
they only need to support the contract.

I would like to allow any mbean that has an "execute" method to be used as
an ant task. Or any mbean that supports a particular contract to be used in
the associated role - without having to change the mbean and make it depend
on ant.

> The type being requested depends on who requests it. Inside or outside
> targets, it's any bean. And I mean really any bean: Doesn't need to


> implement anything Ant-related. This is implicitly what we call today a
> datatype, and they can be id'd. The subset of these beans that also have
> an execute method are also implicitly tasks. The different subsets of
> these beans that implements FileSelector are suitable to use within
> filesets, and tasks deriving from MatchingTask since we're talking about
> it.
> I fail to see what is wrong with this scenario. --DD

I think it is a good scenario, and the JMX uses prove it is viable.
You may like or dislike Jboss - but their modularity and flexibility
( given by JMX and the low-coupling ) is a proven thing.


> -----Original Message-----
> From: Stefan Bodewig []
> Sent: Wednesday, April 23, 2003 11:12 AM
> To:
> Subject: Re: antlib
> On Wed, 23 Apr 2003, Dominique Devienne <> wrote:
>> Forcing roles to map to an interface is probably a *good* idea!
> Maybe, hmm, probably, not convinced ...
>> Every single bean would become implicitly a data-type, and the ones
>> with an execute() method implicitly become tasks. Beyond that, all
>> other roles are interfaces.
> How would you have a task that also is a condition?  It implements
> Condition and has an execute method?
> [DD] Yes! What's wrong with that?
> How would you have a datatype that also is a condition?  This may be
> far-fetched, not sure.
> Stefan

View raw message