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 > > [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] > > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
