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]
