ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: [myrmidon] Move framework outta myrmidon?
Date Thu, 28 Mar 2002 05:02:16 GMT

> -----Original Message-----
> From: Peter Donald []

> > We should do something with DataType, while we're moving stuff around. 
> > It's the only class in framework which is being used by the 
> container.  It
> > might be better off in myrmidon.api.  Another option is to do 
> away with it
> > altogether (my preferred option).
> hmmm. I didn't notice that. Was this something you added? In 
> theory it could 
> completely be removed because I can't see how you would want to use it as 
> DataTypes are not likely to match the role unless they were 
> registered under 
> role in which case the next bit of code will never get executed.
>  // Use the generic 'data-type' role.
>         final TypeFactory factory = m_typeManager.getFactory( 
> DataType.ROLE );
>         if( !factory.canCreate( name ) )
>         {
>             throw new NoSuchPropertyException();
>         }
>         return factory.create( name );
> So can't we just delete that code ?

It's used for 2 (experimental) cases, that are kinda handy:

* Where the add() method's type does not map to a role type, data-type is used as the role.
 This means you don't have to create a role, and can just use plain data-types instead.

* Allows you to use a plain data-type as a nested element instead of a role type, and the
configurer will attempt to convert it to the expected type.

> > Another option for the framework classes would be to move them into
> > antlibs, and drop the 'can't share classes' restriction.  We 
> are going to
> > have to deal with the issue of sharing classes at some stage, 
> because the
> > current solution isn't particularly workable.
> May be quick and easy but ... isn't that the path to the darkside ? ;)
> It encourages too much bad programming practices IMHO so I really 
> don't want 
> to do it.

It *does* encourage bad practice.  What we need is a solution that sits somewhere between
the extremes of no sharing, and opening up everything.  Some controlled sharing would be a
good thing.  For example, we want the stuff in the ant1compat antlib to be visible to those
antlibs that need it, without making it visible to everything.  Same is true of a lot of the
stuff in framework.

We can do this to some degree by fixing up the handling of extensions (resolving them for
jars in lib/, fixing up the classloaders, and so on).  I'm not sure how this will go long
term.  In particular, what would be nice is if an antlib writer could distribute a single
.atl file, rather than a .jar that has to get installed in ${myrmidon.home}/lib, one that
has to get installed in ${myrmidon.home}/ext, and an .atl that has to get installed in the
antlib search path somewhere.


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

View raw message