You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2004/05/17 08:25:18 UTC
[math] Dependencies WAS: Design review pre 1.0
Given all of the recent discussion of dependencies among commons
components, I think we should take a more conservative approach than we
have up to now, duplicating some code / functionality in a few place to
limit dependencies. If we do all of the things below, we will have no
hard dependencies.
>
> 15) Dependencies!!!! commons-discovery can and should be an optional
> dependency. In fact it may already be, as each call to DiscoveryClass
> is in an Exception catch, which ought to trap ClassNotFoundException.
> However, I don't think that the default implementation behaviour is
> actually working which needs fixing.
I agree with Stephen here, if we catch the ClassNotFoundException and just
create a default instance, [discovery] and hence [logging] can be
optional. I also agree with the "getInstance" vs. "newInstance"
semantics, returning cached instances to limit overhead when discovery is
used.
>
> commons-lang is only used for NestableException. This is a dubious
> dependency - the relevant code can be copied, and [lang]s
> ExceptionUtils is perfectly able to handle extracting cause parameters
> by reflection. (Don't copy NestableException - copy the code within)
I think this where we were going originally. We can eliminate the [lang]
dependency by duplicating a small amount of code. I am in favor of this.
>
> commons-logging is not used directly, just via beanutils and discovery
> (and is a classic example of commons chained dependencies that should
> be avoided)
Yes, can be made optional.
>
> 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.
>
> commons-collections TreeBag is used by Frequency - it might be worth
> considering removing this dependency, but it is the hardest.
> (CollectionUtils.NATURAL_COMPARATOR is a simple class to copy)
Frequency originally just used a HashMap; but the TreeBag implementation
is better. This may be painful, but I will have a look at it.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Dependencies WAS: Design review pre 1.0
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
RE: [math] Dependencies WAS: Design review pre 1.0
Posted by Tim O'Brien <to...@discursive.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org