excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <lsim...@jicarilla.org>
Subject component matrix
Date Sat, 19 Jun 2004 13:52:51 GMT
Hi gang!

Even though I just wrote:

  "I like Pete's suggestion of taking this general but vague consensus on
   direction and applying it to individual bits and pieces of code in a
   gradual way. "

I cannot quite resist the temptation to get some "hard" data on where 
we're at. Here's a list I've been making for myself...

This is just brainstorming. Just to give an idea of what we've got here. 
Have by no means made up my mind. Also note all the question marks!

Component           Plan  Dependees
compatibility       X     monitor???
component           D0    testcase,tests(datasource,xmlutil,monitor)
configuration       D1?   -
datasource          K?    -
event               D2    fortress
fortress            K     -
i18n                D3?   datasource,fortress,xmlutil,monitor,logger
instrument          K     plenty
instrument-client   K     -
instrument-manager  K     fortress
lifecycle           K     fortress
logger              K     fortress,xmlutil,testcase,monitor,logger
monitor             C1    fortress-bean???
pool                K?    event,datasource,fortress,xmlutil,monitor
sourceresolve       K     fortress,xmlutil,monitor
store               C2    xmlutil
testcase            D0    datasource,xmlutil,monitor
thread              D4?   -
xmlutil             C3    fortress-bean???

X = archive
D = deprecate
K = keep
C = conditional

X --  means the bugger is tagged then axed. I'd like to get a few things
       out of the way, but since most of that isn't deprecated right now
       I don't think that's fair to our users. Compatibility has no such
       problem so it can go.
       Replacement: commons-cli, commons-collections, commons-io,
         geronimo-naming, tomcat-naming,
         spice-jndikit, spice-salt,

D0 -- I'm not happy with the amount of maintaince ecm is receiving, the
       quality of its docs nor the quality of its tests. Cocoon still
       uses ecm, so we need to keep it around. Preferably we reduce the
       dependencies of our tests on ecm to 0 then move it off to a
       "graveyard" area. Much the same for testcase, which is a bad way
       to write tests anyway.
       Replacement: fortress, junit

D1 -- Merlin no longer uses excalibur-configuration, I think loom
       doesn't use it anymore either. I know of no other users. Would
       like to X later.
       Replacement: commons-configuration, commons-digester,
         spice-configkit, avalon-configuration, xstream

D2 -- While the event package is of reasonable quality, its primary
       maintainer has forked the package and improved it a lot.
       Deprecate, X later. Need to move fortress to use the d-haven
       Replacement: d-haven-event

D3 -- Merlin now uses avalon-i18n (or something). A two-class dependency
       jar is simply not interesting. Primary maintainer has forked and
       improved this package elsewhere.
       Replacement: spice-salt

D4 -- Are there users for this? Certainly haven't seen anyone fix the
       failing testcases or respond to bug reports.
       Replacement: util.concurrent

C1 -- My primary concern with monitor is that there's no-one actively
       maintaining it, there's a lack of documentation and a lack of of
       tests. But since I know of no good replacement, I don't think its
       a good idea to deprecate this. Might make sense to remove
       the fortress-bean dependency on it though.

C2 -- Similar story: lack of maintainance, lack of documentation, lack
       of tests, lack of users. Primary user, cocoon, is as a group not
       very interested in helping to improve the state of this package.
       Again, I know of no good replacement; the only packages I know
       in the same problem space are either commercial (JCache) or very
       different (prevayler).

C3 -- More of the same. Complex package to maintain. Since some people
       are using it, not a good idea to deprecate. But really want to see
       maintainers besides Carsten (who is too busy :-D).



To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/

View raw message