You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/04/23 15:49:29 UTC
[Framework] Declaration of Stability of Pieces
This is a declaration of what I _know_ is stable and supportable
in Avalon Framework, and what I _know_ is not stable in the framework.
After this, what I am aware of that needs to be addressed.
STABLE
------
Framework interface contracts and usage (needs better docs, though).
(AKA org.apache.avalon.**)
Excalibur Component Management Framework
Excalibur Datasources
Excalibur CLI package
Excalibur Concurrent Lock class (other classes I don't know about).
Excalibur IO FileFilters (the other classes?)
Excalibur Pool SingleThreadedPool implementation
UNSTABLE
--------
Framework interface packages (almost done hopefully)
Excalibur i18n package (not sure if it works, or it's applicability
at this level--unnaware if it is used anywhere).
Excalibur Pool multithreaded pool implementations
Excalibur Thread package (it uses Pool package)
UNSURE
------
Excalibur Collections package
Excalibur Concurrent classes other than Lock
Excalibur IO package (non-filefilter)
ACTIONS TO TAKE:
1) Stabilize packages for org.apache.avalon.** What are the known issues?
2) Stabilize Excalibur Pool and Thread packages
3) Move Excalibur i18n to a whiteboard location (i.e. not in avalonapi.jar)
4) Test all the unsure areas. If stable, we keep, if unstable and not easily
fixed, we move to whiteboard location.
5) Document the compenents and interfaces well (ensuring that the description
is consistent).
Please bring to my attention anything I may have missed. Also, note that I
am more than willing to support the Excalibur DataSources and Component Management
framework since I already do.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Framework] Declaration of Stability of Pieces
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> >>Please bring to my attention anything I may have missed. Also, note that I
> >>am more than willing to support the Excalibur DataSources and Component
> >Management
> >>framework since I already do.
>
> More todo after looking at my list.
>
> 8 Make it so that DefaultComponentBuilder will use JAXP1.1 (thus any parser
> can be plugged in), make sure it passes in URLs rather than streams (so
> that external entities from DTD can be found).
Umm, don't take away the stream ability. Validation and DTDs can be expensive
(especially if DTD is on another server). Cocoon has it's own EntityResolvers
and URL handling plugin architecture, and I don't want to lose the ability to
use those.
I have no problems with allowing _both_ approaches though. I think in the end,
it is beneficial to allow that kind of flexibility.
> * Move modifiable to Cocoon2
I can do that today.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Framework] Declaration of Stability of Pieces
Posted by Peter Donald <do...@apache.org>.
>>Please bring to my attention anything I may have missed. Also, note that I
>>am more than willing to support the Excalibur DataSources and Component
>Management
>>framework since I already do.
More todo after looking at my list.
8 Make it so that DefaultComponentBuilder will use JAXP1.1 (thus any parser
can be plugged in), make sure it passes in URLs rather than streams (so
that external entities from DTD can be found).
* Move modifiable to Cocoon2
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] Declaration of Stability of Pieces
Posted by Peter Donald <do...@apache.org>.
At 09:49 23/4/01 -0400, Berin Loritsch wrote:
>STABLE
>------
>Framework interface contracts and usage (needs better docs, though).
> (AKA org.apache.avalon.**)
agreed - after I integrate Leos work into phoenix, update the activity
methods then I will try to do it. Help much appreciated though ;)
>UNSTABLE
>--------
>Framework interface packages (almost done hopefully)
just the activity methods + Enum/ValuedEnum/Version to go.
>Excalibur i18n package (not sure if it works, or it's applicability
> at this level--unnaware if it is used anywhere).
agreed - we prolly should move it to whiteboard
>Excalibur Pool multithreaded pool implementations
>Excalibur Thread package (it uses Pool package)
this could be tricky to stabilize (ie impossible to do in short time) - I
know what needs to be done but it will take a fair bit of time.
>UNSURE
>------
>Excalibur Collections package
stable enough.
>Excalibur Concurrent classes other than Lock
no idea ;)
>Excalibur IO package (non-filefilter)
stable enough.
>ACTIONS TO TAKE:
>
>1) Stabilize packages for org.apache.avalon.** What are the known issues?
Stated above plus the following. The more I think about it the more irksome
I think keeping the package name org.apache.avalon.*. Why? Well when you
ask someone - What is Avalon? It is only natural that they assume
org.apache.avalon IS Avalon. As that assumption is wrong I would really
prefer to name the framework org.apache.framework.*
>5) Document the compenents and interfaces well (ensuring that the description
> is consistent).
Documenting framework is the highest priority - components should be done
after that.
>Please bring to my attention anything I may have missed. Also, note that I
>am more than willing to support the Excalibur DataSources and Component
Management
>framework since I already do.
We need to basically do changelogs, update the xdocs ( a few of them them
have conflicting info), update the website (yay the new logo!), verify all
the builds work (and fix ant files if they don't) and other general release
stuff.
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