I've been experimenting with some refactoring that removes 100% of our dependencies on bean-utils, The first usage was BeanTransformer, the second usage was in DefaultTransformer. I rewrote DefaultTransformer to not need bean-utils with only a few extra lines of code, I expect it is also a bit more efficient because of the removal of extra method calls to been-utils. I'm attempting to do this with BeanTransformer (but its a bit more challenging as its using some bean introspection instead of just attempting to turn the object into a double).
Logging is only in a few places outside of this, I think I can remove this runtime dependency. So in my book I think we reasonably accomplish trimming down the runtime dependencies to the following
commons-discovery commons-collections commons-lang
And trim the compile time dependencies down to
commons-discovery commons-collections commons-lang commons-logging
Does this sound at all reasonable?
-Mark
[EMAIL PROTECTED] wrote:
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]
-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
