You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/03 03:03:12 UTC
Framework -> Stable ???
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 11:01 3/4/01 -0400, Berin Loritsch wrote:
> >Can I ask you what you were trying to accomplish with trying to use the
> >ComponentManager for something other than a Component? It could be a case of
> >using the wrong tool for the task. I believe that Cocoon 2 has the purest
> >implementation of the Component Management Framework.
>
> Essentially I am wanting to pass native JDK objects between components. In
> phoenix this included a implementation of java.security.Policy and
> java.lang.ClassLoader. In other projects I worked on it included
> ThreadGroups, URLConnectionFactory and something else I can't quite
> remember atm ;)
I am not presenting myself as an expert, but it seems that trying to use
the Component Management framework is not the proper mechanism. I think
that the Contextualizable framework would serve you better. In Cocoon,
we use that to pass key File objects and important strings.
Those things you are trying to pass are too fine grained to be Components.
If you have a PolicyManager Component, then you sould use that in the
ComponentManager interface, but again the Centextualizable framework is
the best bet, because there is low overhead in development, and these
things obviously have standard names that you have assigned them.
Just my $0.02 US.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
At 11:01 3/4/01 -0400, Berin Loritsch wrote:
>Can I ask you what you were trying to accomplish with trying to use the
>ComponentManager for something other than a Component? It could be a case of
>using the wrong tool for the task. I believe that Cocoon 2 has the purest
>implementation of the Component Management Framework.
Essentially I am wanting to pass native JDK objects between components. In
phoenix this included a implementation of java.security.Policy and
java.lang.ClassLoader. In other projects I worked on it included
ThreadGroups, URLConnectionFactory and something else I can't quite
remember atm ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 03:16 3/4/01 +0200, Leo Simons wrote:
> >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 think that the org.apache.avalon and org.apache.framework approach would
be the best compromise. So to your original proposal, I will append my +1.
> >> 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 ;)
Personally, until we come up with a way to approach this properly and maintain
the concept of a Component, then we should just keep things as they are ATM.
Can I ask you what you were trying to accomplish with trying to use the
ComponentManager for something other than a Component? It could be a case of
using the wrong tool for the task. I believe that Cocoon 2 has the purest
implementation of the Component Management Framework. I also remember that
when we _used_ to have the NamedComponent and NamedComponentManager we were
trying to blend two different patterns and contracts into one class. That's
why we came up with the ComponentSelector approach.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
At 10:24 4/04/01 -0400, Berin Loritsch wrote:
>Peter Donald wrote:
>>
>> I am off for a bit ... feel free to hack at the proposal so we are closer
>> to decision when I get back.
>
>Where is the Lock code and other utilities?
proposal was never meant to be 100% complete I don't believe - just enough
to give us an idea where to go with main tree.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Peter Donald wrote:
> >
> > I am off for a bit ... feel free to hack at the proposal so we are closer
> > to decision when I get back.
>
> Where is the Lock code and other utilities?
I found where they belong, and I will update with proper code.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> I am off for a bit ... feel free to hack at the proposal so we are closer
> to decision when I get back.
Where is the Lock code and other utilities?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
I am off for a bit ... feel free to hack at the proposal so we are closer
to decision when I get back.
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Stephen McConnell <mc...@osm.net>.
Pete:
How about:
org.apache.avalon.framework...
org.apache.avalon.component...
That gives a split between frameworks and components while maintaining
brand.
Steve.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Thursday, 05 April, 2001 05:40
> To: Avalon Development
> Cc: Avalon Development
> Subject: RE: Framework -> Stable ???
>
>
> At 01:07 5/04/01 +0200, Stephen McConnell wrote:
> >
> >
> >Proposal:
> >
> > org.apache.avalon == the Avalon suite
> > org.apache.avalon.dev == root for packages in Avalon that
> are new, pending
> >testing etc.
>
> I would prefer to have separate hierarchies as it emphasizes there is
> adifference between framework and components. Having a separate one for
> new/pending/testing seems to indicate they are not stable (which may-may
> not) be true.
>
> I see the framework part as being more widely useful than our components.
> However people may not like our pool/datasource/cli/other utils and can
> instead roll their own.
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
At 01:07 5/04/01 +0200, Stephen McConnell wrote:
>
>
>Proposal:
>
> org.apache.avalon == the Avalon suite
> org.apache.avalon.dev == root for packages in Avalon that are new, pending
>testing etc.
I would prefer to have separate hierarchies as it emphasizes there is
adifference between framework and components. Having a separate one for
new/pending/testing seems to indicate they are not stable (which may-may
not) be true.
I see the framework part as being more widely useful than our components.
However people may not like our pool/datasource/cli/other utils and can
instead roll their own.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Stephen McConnell <mc...@osm.net>.
Proposal:
org.apache.avalon == the Avalon suite
org.apache.avalon.dev == root for packages in Avalon that are new, pending
testing etc.
Cheers, Steve.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Wednesday, 04 April, 2001 01:47
> To: Avalon Development
> Subject: RE: Framework -> Stable ???
>
>
>
> Okay I just updated proposal CVS and I think it looks mostly good. The
> pattern I followed for framework classes is
> "org.apache.framework.<aspect>.*". For the components I followed
> convention
> "org.apache.avalon.<component>.*" except for
> org.apache.avalon.aut.* (which
> is meant to be underlying all other components).
>
> Besides the name/branding (ie we can change framework->avalon and
> avalon->???) what do you think?
>
>
>
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
Okay I just updated proposal CVS and I think it looks mostly good. The
pattern I followed for framework classes is
"org.apache.framework.<aspect>.*". For the components I followed convention
"org.apache.avalon.<component>.*" except for org.apache.avalon.aut.* (which
is meant to be underlying all other components).
Besides the name/branding (ie we can change framework->avalon and
avalon->???) what do you think?
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
At 08:43 3/4/01 +0200, Leo Simons wrote:
>Ah. 4.0 should be stable, right?
The framework part, exception part, datsources part .. the rest we are free
to modify ...
>What's the deadline exactly for it to become beta?
Ideally start of may ... realistically ... somewhere mid-may ;)
>I've noticed
>more than a few things in the proposal I think need changing
>before we set them in stone...
>
>(like:
>- improvement of Exception definitions - I don't think they're
>granular enough or properly nested yet
not sure what you mean - give us a demonstration ;)
>- downcasting of return types in several places (can't remember
>right now)
need more details ;)
>(...)
>
>- I have a little list somewhere among this pile of papers...)
kewl ;)
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> Well - I guess the prime example could either be processor package or the
> remaining thread package (ie ThreadContext/ThreadPool/ThreadManager). In
> theory the processor package is nice. It is based on looking at existing
> designs (ie jboss/tomcat/james/cocoon mainly) but as yet we have not
> incorporated it widely enough to see if it really is worthwhile.
>
> Also the same with ThreadContext/ThreadPool/ThreadManager - I have been
> using the same interfaces for close to 2 years but it hasn't seen wide
> application yet. I suspect that we will in the future require the addition
> of something like a ThreadControl to send signals/interupts and other odd
> things.
Well, the Thread stuff is dependant on the pools. I need to apply the same
approach to the Avalon pools as I did for Cocoon and DataSources. I'm just
swamped.
Until that time, it won't be stable on SMP systems--and possibly even on
single processor systems.
> >> * If it is utility code then we only stabilize it if (1) directly uses it
> >> or C2 and it's clients will use it.
> >
> >Lock, Framework Interfaces, Configuration, DataSources, is there anything I
> >am missing?
>
> CascadingThrowable/ExceptionUtil is about the only other thing that pops
> into mind.
Cool beans.
> >What about the decision to backport the ComponentManagement classes used in
> >Cocoon 2? Is that on hold, or is that going to hurry up now?
>
> I am not sure I fully understand it - I would like to backport it but thats
> is up to you ;) If you think it is bonza then we can backport it.
The only thing is getting the Role -> Default Implementation mapping abstracted.
I can't remember where we left off with that. Other than that everything is
copasthetic
> >> Given this I propose that the following 2 hierarchies
> >> * org.apache.framework (stable framework code)
> >> * org.apache.avalon (unstable/untested code or components)
> >
> >I thought the whole framework was Avalon?
>
> Well I guess it is a naming thing. It is really hard to "sell" avalon
> because it includes everything - including the kitchen sink ;) I want to
> separate out the stable from non-stable and I thought this was the best way
> to do it. I am really open to anything ... the only limitation is time
> because we need to be stable before c2 is.
I think it will be an acceptible comprimise.
> >> 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
> >
> >* DataSourceComponents
> >
> >They are _very_ well tested by a number of Cocooners, and the only bug
> >reported has been addressed.
>
> It has been well tested but it is not "framework". It doesn't form part of
> components lifecycle or management etc. In fact it could be reimplemented
> independent of Avalon/Framework in theory.
Point taken.
> For instance a new component just added to commons (namely pool) is IMHO
> better than our version of pool. It wasn't until I saw it that I saw our
> version was lacking (also when I tried to pool datagram-packets that it is
> impossible to implement poolable with). Ideally if that proves to be better
> in long run it would be better to allow us to switch in that implementation.
Any improvements will be appreciated.
> I agree we should stabilize it though (maybe even marking it as stable in
> javadocs) however I don't think it should be in same repository as other
> lifecycle orientated code.
Agreed.
> >> 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).
> >
> >Looking forward to seeing it. We are talking about the /proposal heirarchy
> >in this discussion right?
>
> Yep - I will probably check it in tomorrow .. SAMBA has crashed and I
> currently can't access my code to commit it ;l
Don't you just love it when software works !P
> >> 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.
> >
> >That would make it more consistent with the JavaBean approach. But then I
> >have to ask, "Why have a COMPONENT management interface?". The idea was to
> >keep the Components conceptually separate from regular classes. Components
> >manipulate Classes, either through containment or through some other means.
>
> That was the idea - the question I am really asking I guess is the
> conceptual purity worth the impracticality. Some days I would say yes -
> other days I say no. In general useage I would say no but for building
> other frameworks I would say yes ... so I am not sure ;)
Since you are vasilating so much, I would suggest keeping it the way it is
until you can objectively quantify and qualify why you want to remove the
Component interface. So for version 4.0 we keep the Component interface.
I think that conceptually, having the Component interface helps to force
the thinking in a Component Oriented Programming mindset--as opposed to
simply an Object Oriented Programming mindset.
In theory, a Component does not have to be expressed in an Object Oriented
fashion. An example of this is CORBA C binding. You have specified the
Component by interface, but you implemented it in an Procedural Language.
In practicality, Avalon does not use CORBA, so we can be assured that we
are manipulating Java objects. Clients need to expect an Interface, not
a Class. The implementation of that Interface is returned to them. I must
say, that I debated whether or not to import and use the javax.sql.DataSource
interface for the DataSourceComponent code. The reason I ended up not doing
that is because I was providing an access mechanism to a client that may
not have that interface in the classpath. The reason I chose the longer
class name is to avoid confusion over the javax version vs. the Avalon
version.
It would have been handy to return a javax.sql.DataSource object, but in the
end, the separate Component (that I used as a Proxy or Wrapper for the javax
in the J2EE version) was both conceptually and practically the right way
to go.
>
> >> Votes/Comments/proposals/etc?
> >
> >I am totally for Apache Avalon's Framework to be Beta and not changed. I
> will
> >help in any way I can.
>
> excellent!
> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Leo Simons <ma...@leosimons.com>.
> >> Initially I wanted to separate out implementation and
> interfaces but given
> >> our tight deadline I no longer think that is pertinent for
> this version.
> >
> >Are we talking an official version 3.x or version 4.0?
>
> I was thinking we up the framework classes to 4.0...
Ah. 4.0 should be stable, right?
What's the deadline exactly for it to become beta? I've noticed
more than a few things in the proposal I think need changing
before we set them in stone...
(like:
- improvement of Exception definitions - I don't think they're
granular enough or properly nested yet
- downcasting of return types in several places (can't remember
right now)
(...)
- I have a little list somewhere among this pile of papers...)
cheers!
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Peter Donald <do...@apache.org>.
At 09:03 3/4/01 -0400, Berin Loritsch wrote:
>> 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.
>
>I agree. Does this include Camelot? I think that has been the most dynamic
>part of Avalon to date.
I don't think it is stable enough yet. I want to separate it out like Fede
wanted but it has not been tested enough yet.
>> 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
>
>The datasources are pretty much stabilized. I haven't heard too much on this
>list or Cocoon lately about them.
>
>> * If it is not sufficiently general or only applicable "in theory" then we
>> don't stabilize it yet
>
>Not sure on this point. I get the point you are making, but I want to know
>what you mean by "in theory".
Well - I guess the prime example could either be processor package or the
remaining thread package (ie ThreadContext/ThreadPool/ThreadManager). In
theory the processor package is nice. It is based on looking at existing
designs (ie jboss/tomcat/james/cocoon mainly) but as yet we have not
incorporated it widely enough to see if it really is worthwhile.
Also the same with ThreadContext/ThreadPool/ThreadManager - I have been
using the same interfaces for close to 2 years but it hasn't seen wide
application yet. I suspect that we will in the future require the addition
of something like a ThreadControl to send signals/interupts and other odd
things.
>> * If it is utility code then we only stabilize it if (1) directly uses it
>> or C2 and it's clients will use it.
>
>Lock, Framework Interfaces, Configuration, DataSources, is there anything I
>am missing?
CascadingThrowable/ExceptionUtil is about the only other thing that pops
into mind.
>What about the decision to backport the ComponentManagement classes used in
>Cocoon 2? Is that on hold, or is that going to hurry up now?
I am not sure I fully understand it - I would like to backport it but thats
is up to you ;) If you think it is bonza then we can backport 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 thought the whole framework was Avalon?
Well I guess it is a naming thing. It is really hard to "sell" avalon
because it includes everything - including the kitchen sink ;) I want to
separate out the stable from non-stable and I thought this was the best way
to do it. I am really open to anything ... the only limitation is time
because we need to be stable before c2 is.
>> Initially I wanted to separate out implementation and interfaces but given
>> our tight deadline I no longer think that is pertinent for this version.
>
>Are we talking an official version 3.x or version 4.0?
I was thinking we up the framework classes to 4.0...
>> 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
>
>* DataSourceComponents
>
>They are _very_ well tested by a number of Cocooners, and the only bug
>reported has been addressed.
It has been well tested but it is not "framework". It doesn't form part of
components lifecycle or management etc. In fact it could be reimplemented
independent of Avalon/Framework in theory.
For instance a new component just added to commons (namely pool) is IMHO
better than our version of pool. It wasn't until I saw it that I saw our
version was lacking (also when I tried to pool datagram-packets that it is
impossible to implement poolable with). Ideally if that proves to be better
in long run it would be better to allow us to switch in that implementation.
I agree we should stabilize it though (maybe even marking it as stable in
javadocs) however I don't think it should be in same repository as other
lifecycle orientated code.
>> 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).
>
>Looking forward to seeing it. We are talking about the /proposal heirarchy
>in this discussion right?
Yep - I will probably check it in tomorrow .. SAMBA has crashed and I
currently can't access my code to commit it ;l
>> 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.
>
>That would make it more consistent with the JavaBean approach. But then I
>have to ask, "Why have a COMPONENT management interface?". The idea was to
>keep the Components conceptually separate from regular classes. Components
>manipulate Classes, either through containment or through some other means.
That was the idea - the question I am really asking I guess is the
conceptual purity worth the impracticality. Some days I would say yes -
other days I say no. In general useage I would say no but for building
other frameworks I would say yes ... so I am not sure ;)
>> Votes/Comments/proposals/etc?
>
>I am totally for Apache Avalon's Framework to be Beta and not changed. I
will
>help in any way I can.
excellent!
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Framework -> Stable ???
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> 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.
I agree.
> 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.
C2 presents a number of significant improvements over C1, including the
framework. I don't know about JAMES's userbase, but between JAMES and
Cocoon 2, we have pretty much finalized the framework as far as class
content. The current Configuration classes are MUCH easier to use, and
almost a pleasure.
> 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.
I agree. Does this include Camelot? I think that has been the most dynamic
part of Avalon to date.
> 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
The datasources are pretty much stabilized. I haven't heard too much on this
list or Cocoon lately about them.
> * If it is not sufficiently general or only applicable "in theory" then we
> don't stabilize it yet
Not sure on this point. I get the point you are making, but I want to know
what you mean by "in theory".
> * If it is utility code then we only stabilize it if (1) directly uses it
> or C2 and it's clients will use it.
Lock, Framework Interfaces, Configuration, DataSources, is there anything I
am missing?
What about the decision to backport the ComponentManagement classes used in
Cocoon 2? Is that on hold, or is that going to hurry up now?
> Given this I propose that the following 2 hierarchies
> * org.apache.framework (stable framework code)
> * org.apache.avalon (unstable/untested code or components)
I thought the whole framework was Avalon?
> Initially I wanted to separate out implementation and interfaces but given
> our tight deadline I no longer think that is pertinent for this version.
Are we talking an official version 3.x or version 4.0?
> 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
* DataSourceComponents
They are _very_ well tested by a number of Cocooners, and the only bug
reported has been addressed.
> 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 need to backport the Pool framework from Cocoon2 to Avalon. I found the
race conditions, and the DataSourceComponents and ComponentPool (C2) use the
architecture. Santiago Gala (the only one I *know* has a MP box) has tested
those two pools to the best of his ability, and doesn't get a lockup.
> 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).
Looking forward to seeing it. We are talking about the /proposal heirarchy
in this discussion right?
> 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.
That would make it more consistent with the JavaBean approach. But then I
have to ask, "Why have a COMPONENT management interface?". The idea was to
keep the Components conceptually separate from regular classes. Components
manipulate Classes, either through containment or through some other means.
> Votes/Comments/proposals/etc?
I am totally for Apache Avalon's Framework to be Beta and not changed. I will
help in any way I can.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Framework -> Stable ???
Posted by Leo Simons <ma...@leosimons.com>.
> Hence I propose that we move the "framework" part of avalon to a stable
> beta release to match c2s going beta.
+1
> * 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.
perhaps org.apache.avalon for the framework
and org.apache.avalon-util (.aut) for utilities
and org.apache.cornerstone for the components?
> 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 :-(.
> 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.
greetz!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon Brand
Posted by Peter Donald <do...@apache.org>.
At 07:26 4/4/01 +1000, Peter Donald wrote:
>At 08:43 3/4/01 +0200, Leo Simons wrote:
>><snipped>
>>> To that end, I propose the following heirarchy:
>>>
>>> org.apache.avalon (stable subpackages and interfaces, etc.)
>>>
>>> org.apache.avalon.untested (packages and classes, etc under development)
>>
>>This seems the better solution from a marketing POV. Also, it
>>removes some duplicity in naming (when accessing cvs, new users
>>might think "framework? I thought Avalon was the framework". I
>>just saw an existing user think that =).
>>
>>Perhaps it shouldn't be "untested" but "alpha" or
>>"development". Doesn't matter that much. My +1.
>
>I would prefer a whole other name/brand for that ...
>org.apache.???.*
or maybe org.apache.avalon.framework.* for framework (which is stable) and
org.apache.avalon.* for the rest???
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon Brand
Posted by Peter Donald <do...@apache.org>.
At 08:43 3/4/01 +0200, Leo Simons wrote:
><snipped>
>> To that end, I propose the following heirarchy:
>>
>> org.apache.avalon (stable subpackages and interfaces, etc.)
>>
>> org.apache.avalon.untested (packages and classes, etc under development)
>
>This seems the better solution from a marketing POV. Also, it
>removes some duplicity in naming (when accessing cvs, new users
>might think "framework? I thought Avalon was the framework". I
>just saw an existing user think that =).
>
>Perhaps it shouldn't be "untested" but "alpha" or
>"development". Doesn't matter that much. My +1.
I would prefer a whole other name/brand for that ...
org.apache.???.*
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Avalon Brand
Posted by Leo Simons <ma...@leosimons.com>.
<snipped>
> To that end, I propose the following heirarchy:
>
> org.apache.avalon (stable subpackages and interfaces, etc.)
>
> org.apache.avalon.untested (packages and classes, etc under development)
This seems the better solution from a marketing POV. Also, it
removes some duplicity in naming (when accessing cvs, new users
might think "framework? I thought Avalon was the framework". I
just saw an existing user think that =).
Perhaps it shouldn't be "untested" but "alpha" or
"development". Doesn't matter that much. My +1.
cheers!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Avalon Brand
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Peter Donald [mailto:donaldp@apache.org] wrote:
> Subject: Framework -> Stable ???
> [snip]
> > 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.
> [snip]
> > Given this I propose that the following 2 hierarchies
> > * org.apache.framework (stable framework code)
> > * org.apache.avalon (unstable/untested code or components)
[ SNIP ]
> While a strongly support the suggestions to establish a stable (potentially
> reduced/rationalised) code base I strongly urge everyone to consider the
> brand impact that packages play. Changing the main package to a non-Avalon
> name will immediately reduce the accrued brand value of Avalon, and will put
> in place the framework for progressive degrade of Avalon brand awareness.
>
> Instead on changing packages, I recommend that the package names remains the
> same, but that the non-stable parts be repackaged under Avalon
> sub-packages - AND that appropriate documentation is provided about
> subpackages, purpose, utility, stability, etc.
These are very good arguments, Steve. I am inclined to align with you on this
one. To that end, I propose the following heirarchy:
org.apache.avalon (stable subpackages and interfaces, etc.)
org.apache.avalon.untested (packages and classes, etc under development)
the heirarchy of the "untested" package should mirror how they will be merged
into the main package. There should be a package.html file in the root "untested"
directory that explains that once the utility/component/interface is ready for
prime-time, the package name will change. There should also be a disclaimer
for that code so that users will know it is a "use at your own risk" type of
thing.
The name "untested" does not imply instability (although that may very well
apply), but merely that we can't guarantee the usability or stability of
API of the code yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Avalon Brand
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald [mailto:donaldp@apache.org] wrote:
Subject: Framework -> Stable ???
[snip]
> 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.
[snip]
> Given this I propose that the following 2 hierarchies
> * org.apache.framework (stable framework code)
> * org.apache.avalon (unstable/untested code or components)
I am very strongly opposed to this suggestion on brand and marketing
grounds. This sends the message the "AVALON" == unstable/untested. This
reinforces opinion that Avalon isn't ready - irrespective of the actions
taken in achieving a stable framework. Back on the 1-April, Pete posted a
URL to this list referencing an Article all about framework and why they are
needed. This article was arguing the key virtues of global Avalon picture,
and yet the only reference to Avalon was reference at the end of the paper
which stated the following:
Extract, "Frameworks Save the Day", Humphrey Sheil,
http://www.javaworld.com/jw-09-2000/jw-0929-ejbframe.html
"When I began researching this article, I ran across
Avalon pretty early on. It's a framework project under
the Java Apache umbrella that aims to "create, design,
develop, and maintain a common framework for server
applications written using the Java language." Avalon
will be a very powerful framework once it matures, and
its scope goes far beyond anything considered here.
However, I don't think it's ready for prime time, so I
didn't cover it in the article. It's definitely one to
watch, though.
Take a look at this statement and draw some conclusions:
1. "Avalon" has establish brand value
2. "Avalon" brand is aligned with "very powerful"
3. The Avalon process is probably six months off the radar
if your looking for an immediate solution
4. For anyone playing with forward-looking radars, the
"Avalon" brand is the key to track.
While a strongly support the suggestions to establish a stable (potentially
reduced/rationalised) code base I strongly urge everyone to consider the
brand impact that packages play. Changing the main package to a non-Avalon
name will immediately reduce the accrued brand value of Avalon, and will put
in place the framework for progressive degrade of Avalon brand awareness.
Instead on changing packages, I recommend that the package names remains the
same, but that the non-stable parts be repackaged under Avalon
sub-packages - AND that appropriate documentation is provided about
subpackages, purpose, utility, stability, etc.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org