All beanutils is benefiting us with is a "NumberTransformer" that was easy to write. This could/should be made somewhat plugable. Right now BeanUtils usage is in an anonymous NumberTransformer innerclass within BeanListUnivariateImpl:
new NumberTransformer() {/**
* @see org.apache.commons.math.util.NumberTransformer#transform(java.lang.Object)
*/
public double transform(final Object o) throws MathException {
try {
return (
(Number) PropertyUtils.getProperty(
o,
getPropertyName()))
.doubleValue();
} catch (IllegalAccessException e) {
throw new MathException(
"IllegalAccessException in Transformation: "
+ e.getMessage(),
e);
} catch (InvocationTargetException e) {
throw new MathException(
"InvocationTargetException in Transformation: "
+ e.getMessage(),
e);
} catch (NoSuchMethodException e) {
throw new MathException(
"oSuchMethodException in Transformation: "
+ e.getMessage(),
e);
}
}
};
-Mark
Tim O'Brien wrote:
Phil Wrote....
commons-beanutils doesn't seem to be used, so shouldn't be in project xml
BeanUils is used in the "BeanList" stuff that I recently rectified but have not moved back into src from test. I guess I am in favor of relegating this to experimental and dropping the dependency for 1.0.
[Tim O'Brien]
Yes, 100% go for it. I wonder if we can release a supplemental (separate) deliverable that would provide some less important utilities that needed these dependencies.
In other words, a core math library with zero or one dependency, and a supplemental that adds capabilities that depend on other commons libraries.
Confusing or interesting: What do you think?
Tim
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
