Hi, Cocoon2 is just about to go beta which means we have to put out a beta version of the framework classes. Why is this important ? There is a number of reasons that this is a significant event for Avalon. Unlike other projects that use Avalon this project is another "framework" which means other people will be using Coccon2 to build further products.
If C2s acceptance is anywhere in the vaccinity that I expect it to be then there will be a significant number of C2 adopters who will thus be indirectly programming to the avalon interfaces. I find it within bounds of reason that we get C2 or James to keep up with Avalon when they are alpha or don't have "clients" that directly use Avalon. However I find it completely unnacceptable for C2s clients to be stuffed around due to changes in Avalon. Hence I propose that we move the "framework" part of avalon to a stable beta release to match c2s going beta. This means that once we commit to a particular arrangement we will effectively required to support them for a long duration into the future. Given this I think we should do the minimalist thing to the greatest possible degree. If a pattern is not stable and applicable to a sufficiently wide an audience it should not be included in the stable framework. Included in jakarta-avalon CVS is 1. Framework/Pattern code 2. Utility code 3. Components The most important of which to stabilize is (1). It is expected that overtime (3) will be upgraded and (2) is minimal. So I propose the following guidelines; * 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) Initially I wanted to separate out implementation and interfaces but given our tight deadline I no longer think that is pertinent for this version. So what do I think should be in org.apache.framework (looking at arrangement in current proposal CVS) * Configuration package * ComponentManager package * Context package * Lifecycle package * Logger package (Contains *Loggable) * part of thread package (namely ThreadSafe/SingleThreaded) * CascadingExceptions and ExceptionUtil Everything else would remain in org.apache.avalon for the moment. In the future when Camelot is simplified into smaller packages (ie container/registry etc) this would be moved across to framework. Also when the ThreadContext/ThreadPool/ThreadManager/etc interfaces are adapted further they would be moved across. The rest is either components (ie datasource.*/pool.*) or as yet untested extensively (ie processor). The framework/utility code that remains that C2 uses should either be treated as semi stable (ie datasource.*/Lock) or moved into cocoon2 CVS (ie Modifiable). I will update the proposal directory with an outline of what I believe is the right way to do this. Then we can get to voting/opinions/niggles etc. Once we do this we have to develope a strategy to update the current users of avalon to use this new code (and if we start a new CVS for it like jakart-avalon-framework). 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. Votes/Comments/proposals/etc? 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]
