15) Dependencies!!!! commons-discovery can and should be an optional dependency. In fact it may already be, as each call to DiscoveryClass is in an Exception catch, which ought to trap ClassNotFoundException. However, I don't think that the default implementation behaviour is actually working which needs fixing.
I agree with Stephen here, if we catch the ClassNotFoundException and just create a default instance, [discovery] and hence [logging] can be optional. I also agree with the "getInstance" vs. "newInstance" semantics, returning cached instances to limit overhead when discovery is used.
commons-lang is only used for NestableException. This is a dubious dependency - the relevant code can be copied, and [lang]s
ExceptionUtils is perfectly able to handle extracting cause parameters
by reflection. (Don't copy NestableException - copy the code within)
I think this where we were going originally. We can eliminate the [lang] dependency by duplicating a small amount of code. I am in favor of this.
commons-logging is not used directly, just via beanutils and discovery (and is a classic example of commons chained dependencies that should be avoided)
Yes, can be made optional.
commons-beanutils doesn't seem to be used, so shouldn't be in project xml
BeanUils is used in the "BeanList" stuff that I recently rectified but have not moved back into src from test. I guess I am in favor of relegating this to experimental and dropping the dependency for 1.0.
commons-collections TreeBag is used by Frequency - it might be worth considering removing this dependency, but it is the hardest. (CollectionUtils.NATURAL_COMPARATOR is a simple class to copy)
Frequency originally just used a HashMap; but the TreeBag implementation is better. This may be painful, but I will have a look at it.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
