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]

Reply via email to