commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Cliff <m...@mattcliff.com>
Subject Re: [Math] common-math and bloated 3rd party librarie
Date Fri, 07 Nov 2003 22:43:49 GMT
Mark:

   What is your plan for the BeanTransformer.transform() method regarding 
logging/exception throwing? (in particular as to how the current junit 
test is executing)

On Thu, 6 Nov 2003, Mark R. Diggory wrote:

> Brent,
> 
> 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
> 
> brent@worden.org 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > 
> 
> 

-- 
      Matt Cliff            
      Cliff Consulting
      303.757.4912
      720.280.6324 (c)


      The label said install Windows 98 or better so I installed Linux.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message