> 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)
>
Right now my implementations of the NumberTransformer look like this:
public interface NumberTransformer {
double t
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
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 confl
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
als
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-beanutil
