At 03:16 3/4/01 +0200, Leo Simons wrote: >> * If it is a component we don't stabilize it yet >> * If it is not sufficiently general or only applicable "in theory" then we >> don't stabilize it yet >> * If it is utility code then we only stabilize it if (1) directly uses it >> or C2 and it's clients will use it. >> >> Given this I propose that the following 2 hierarchies >> * org.apache.framework (stable framework code) >> * org.apache.avalon (unstable/untested code or components) > >I have my doubts about the name "framework" as this removes the >direct reference to Avalon, which is not wise from a marketing POV.
actually that was one of the issues I was trying to address ;) When people hear avalon they tend to think of a particular part of it * cocooners think of framework part or components part (ie pool/datasource*). * general jakarta peeps think of it as an application server * some people think of it as a repository of utility code etc I know it would be nice to brand it "avalon" or something it is just how we do it that matters ;) >perhaps org.apache.avalon for the framework >and org.apache.avalon-util (.aut) for utilities >and org.apache.cornerstone for the components? Well cornerstone is components hosted by the kernel so IMHO it is not really appropriate for free standing components. In an absolute ideal situation I would like to see org.apache.aut.* (utility) org.apache.avalon/framework.* (framework) org.apache.agora/???.* (components) however I don't have the cycles for that at the moment - especially not if we plan to go beta by the time c2 goes beta. So hence the compromise ;) Though if someone else wanted it badly enough ... >> I will update the proposal directory with an outline of what I believe is > >have you tried building from it yet? There are many import statements to >be updated there. I fixed the majority on my home system, but I can't >commit them because of cvs probs :-(. I fixed them today but I haven't checked in my changes .. will do it real soon now ;) >> Anyway thats the basic outline of something we can do. One thing I do have >> a query about is whether we want to keep the interface "Component" around. >> Currently "Component" is what is returned from ComponentSelector and >> ComponentManager which means that any components stored in those objects >> must implement COmponent. This can be a PITA when you want to store JDK >> type objects in the CM - I have run afoul of it a number of times and have >> a number of classes who only exist to implement Component. Hence I would >> like to make CM and ComponentSelector return Object instead and completely >> remove the Component interface. > >I've seen the problem too. But the disadvantage is the removal of the >conceptual >"Component". A way to avoid that would be to have > >Component ComponentManager.generateComponentFrom(java.lang.Object object); > >which wraps the thing. Might be some complicated rtti stuff there, though. yep I am not really sure how to handle this ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
