ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [myrmidon] Move framework outta myrmidon?
Date Thu, 28 Mar 2002 07:30:31 GMT
On Thu, 28 Mar 2002 16:02, Adam Murdoch wrote:
> > 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.

Really don't like that use ;) Seems like an ugly hack. Either it is pluggable 
or its not. And if it is pluggable we want it to be as strongly typed as 
possible (ie it implements the correct interface) and all objects that 
implement a role interface should register themselves under that role.

> * 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.

Hmm not sure what use this is. If you wanted this behaviour why not just add 
in something like

addName( MyType myType )

? 

I think I must be missing something.

> 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.

True. Hmm ... I really think that the extension mechanism can be made to do 
this. I really don't want users having to worry about mucking about with all 
this stuff. It may be an absolute PITA for us to code it but I think that is 
better than making users suffer. 

How about we try enhancing the extension / classloader system so that we can 
have multi-parent classloaders (assuming disjoint class sets). The we try and 
build an appropriate dependency tree for each library dependency tree. if we 
detect conflicts (ie dependency 1 uses X lib in classloader A while 
dependency 2 uses X lib in classloader B) then we throw an exception and hope 
things work out for the best ;)

Really don't know.

> 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.

Yer. needs redoing. I need to redo it in phoenix aswell and may try tackling 
them both at the same time. Then again I am not sure when I can get to it. 
For the time being my main aim is breaking down the build system and 
documentation. 

-- 
Cheers,

Pete

The avalanche has already started. It is too late for 
the pebbles to vote.  -Ambassador Kosh

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message