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???
Legenda ------- 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,
util.concurrentD0 -- 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, junitD1 -- 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, xstreamD2 -- 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
package.
Replacement: d-haven-eventD3 -- 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-saltD4 -- Are there users for this? Certainly haven't seen anyone fix the
failing testcases or respond to bug reports.
Replacement: util.concurrentC1 -- 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).
cheers,
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
