ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: cvs commit: jakarta-ant-myrmidon/framework/src/java/org/apache/myrmidon/framework/filters
Date Thu, 25 Apr 2002 04:46:22 GMT
On Thu, 25 Apr 2002 12:48, Peter Donald wrote:

> Currently there can not be multiple roles with same classname but different
> classdata

Yes, I know.  Doing away with that restriction is the whole point.

> and I can't honestly see where it would be viable.

We are awful close to being able to drop in two different versions of an 
antlib, and have it work.  Not necessarily in the same project, but certainly 
across projectrefs or <ant> calls.  The main issue is naming - obviously this 
isn't going to work if we have a global role namespace.

> Java is not designed to work that way

No?  Bugger.  That's going to make things harder, I guess :)

> and until we go
> there I don't see any need to burden the rest of the system with
> complexitites until we know we are going to use it.

Ok. I'm not planning on ignoring complexity.  What I'd like to do is to *try* 
to solve the issues we have with roles (can't have more than one with the 
same name, can't have a typeless role, that kinda thing), without impacting 
complexity too much.  If it turns out to be horribly complex, then, we just 
have to let it go.  I think it's worth exploring.

> Given that the classname is not meaningless - it accurately describes
> exactly what the role is ;)

Fair enough.  Not meaningless.  But not any more meaningful than the short 
name, either.

> I would be opposed to untyped roles but you knew I would say that :)

Yeah, I knew.  Would you be opposed to making them available to task writers 
to use, without us using them in myrmidon, and provided they fell out of 
whatever role solution we come up with?

> The longer ones map to physical representations. It is easy to verify if a
> component actually implements service by checking the interfaces
> implemented by component and see if one of them has same name as role
> (minus any decoration if necessary).

Checking the name doesn't guarantee much at all when the component, the role, 
and the thing doing the checking are all in different classloaders.  That's 
why we added the role's Class object to the role registry - to make the check 

> If you are a user you need not know about physical name or suffer through
> ClassLoader hell. If you are a develoepr you need not know the logical
> name.

You do if you are writing something that sits between the user and the 
internals.  Like, say, a task.  Or if you happen to be working on the 
infrastructure: What's this name here?  Is is a short name, a long name, a 
class name?  Ug.

Like I said before, if we were to change a role's (programmatic) identifier 
from the role's class name, to the role's Class object, then it really 
doesn't matter what the role names are.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message