I used DynaBeans to enable addValue as well. I am +1 to dropping from 1.0 so we can
remove this dependency. Not a bad idea to eventually produce an extensions, optional
or examples jar as well.
Frequency is kind of basic, but it could in theory also fit into this category, since
it is the only user of [collections]. I am looking at how to code around that
dependency, but this is another thing to think about.
Phil
-----Original Message-----
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Mon 5/17/2004 9:57 AM
To: Jakarta Commons Developers List
Cc:
Subject: Re: [math] Dependencies WAS: Design review pre 1.0
Yes, I had placed it into test a while back which reduced it to a build
time dependency as opposed to a runtime dependency. Originally, I was
attempting to isolate this as an example as opposed to a Class which
users would utilize, so I was working hard to remove it from the
distribution jar.
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]
