commons-logging: A little more investigation revels, commons-beanutils depends on commons-logging. Hence, the only way to remove commons-math's dependency on commons-logging, is to remove commons-math's dependency on commons-beanutils. So, as long as commons-math is dependent on commons-beanutils, nothing is gained, in terms of bloat, by removing the commons-logging dependency.
My stance is to use commons-logging. commons-discovery: Since I added the discovery stuff I will be its advocate. One of the visions for commons-math is to create a kind of service provider API for math routines and break commons-math into two logical parts: the SPI and the default implementation. Then, commons-math would either invite other service providers (Mathematica, MatLab, S-Plus, ...) to create adaptors or we would develop them. The route we have chosen to enable the SPI is via the abstract factories. To instantiate concrete factory instances, I decided to use the features provided by commons-discovery. Prior to its injection, the concrete factories used system properties for instantiation. This is limiting in the sense only one service provider can be used per JVM and in a app server type deployment, there may be a need to have utilize many different service provides for different applications. With commons-discovery, the system property approach is still supported along with properties files and the Jar SPI specification. The later two would enable the possibility of have multiple service providers under one JVM. Thus, using commons-disovery nothing is lost over the original implementation and some nice flexibility is gained. My stance is to use commons-discovery. commons-collections: commons-lang: commons-beanutils: No one seems to be objecting to these much so won't bother defending our reasons for using them. Here's a thought. One thing we might do to limit the proliferation of jars is to create a jar containing commons-math as all of its dependencies. Maven has an uberjar plugin that might be the ticket to creating such a jar. There ares risk with deploying such a jar as there might be version conflicts if other versions of the dependencies are deployed separately. I'm not a big advocate of this strategy (I've had to many struggles working with products that came bundled with old version of xerces) but it might be to quell some of the dependency backlash. Brent Worden http://www.brent.worden.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
