I agree with the views in this email. While I agree that there is a line
between whether something should go in a project or not [and this still
applies to Lang], I don't believe that Rodney's suggested criteria will
work as they would lead to Stephen's examples. Any criteria which cannot
be applied retroactively and produce sane results, will not work for the
future.

It doesn't even make sense in Rodney's own examples as a [time] project
and a [math] project do not currently make any sense. If we're going to
have a [time] project, we should just invite Joda-time in, and if we're
going to have a [math] project it ought to have enough functionality in it
to be worth doing. Any [math] project with enough functionality would, in
my opinion, no longer be for the common developer but for mathematicians,
in which case it is outside the scope of Jakarta Commons.

[functor] is worthy of argument, [I have long hovered on the fence on
functor], as it _just_ has the size and scope to be a project.
[exceptions] is an example of a project which lacks the scope to be a
project.

Lastly, I continue to believe that Jars are similar to Taglibs. While a
million tiny jars are or taglibs are easier to maintain dependencies
between [even if one is not reusing things but inlining them], JSTL's
success has shown that the user does not want a million tiny jars.

Hen

On Wed, 1 Jan 2003, Stephen Colebourne wrote:

> Let me attempt to demonstrate why multiple jars won't work. Imagine we do
> the split of [lang] into jars based on Common Reuse/Reuse-Release
> Equivalence/Common Closure Principles.
>
> [arrayutil]
> ArrayUtils.java
> - depends on [builder]
>
> [booleanutil]
> BooleanUtils.java
> - depends on [numberutil]
>
> [charsetutil]
> CharRange.java
> CharSet.java
> CharSetUtils.java
>
> [stringutil]
> RandomStringUtils.java
> StringUtils.java
>
> [classutil]
> ClassUtils.java
>
> [notifierutil]
> Notifier.java
> NotifierException.java
> - depends on [exception]
>
> [numberutil]
> NumberUtils.java
>
> [objectutil]
> ObjectUtils.java
>
> [serializationutil]
> SerializationUtils.java
> SerializationException.java
> - depends on [exception]
>
> [systemutil]
> SystemUtils.java
>
> [builder]
> CompareToBuilder.java
> EqualsBuilder.java
> HashCodeBuilder.java
> StandardToStringStyle.java
> ToStringBuilder.java
> ToStringStyle.java
> - depends on [numberutil], [systemutil]
>
> [enum]
> Enum.java
> EnumUtils.java
> ValuedEnum.java
>
> [exception]
> ExceptionUtils.java
> Nestable.java
> NestableDelegate.java
> NestableError.java
> NestableException.java
> NestableRuntimeException.java
> - depends on [arrayutil], [systemutil]
>
> [functor]
> Executor.java
> ExecutorException.java
> ExecutorUtils.java
> Factory.java
> FactoryException.java
> FactoryUtils.java
> Predicate.java
> PredicateException.java
> PredicateUtils.java
> Transformer.java
> TransformerException.java
> TransformerUtils.java
> - depends on [exception], [serialization]
>
> [numberrange]
> DoubleRange.java
> FloatRange.java
> IntRange.java
> LongRange.java
> NumberRange.java
> Range.java
> - depends on [numberutil]
>
> [fraction]
> Fraction.java
>
> [reflect]
> ConstructorUtils.java
> FieldUtils.java
> MethodUtils.java
> ReflectionException.java
> ReflectionUtils.java
> package.html
> - depends on [arrayutil], [classutil], [stringutil], [exception]
>
> [timeutil]
> CalendarUtils.java
> DateUtils.java
>
> [timingutil]
> StopWatch.java
>
> [bitfield]
> BitField.java
>
> [identifier]
> IdentifierUtils.java
> - depends on [functor]
>
> [validate]
> Validate.java
>
> So, 22 new commons components. <sarcasm>Now thats a good idea isn't
> it</sarcasm>
>
> And if you think this is pedantic look at the list again. Any combination of
> the above components is combining two concepts that don't have a direct
> connection.
>
> Because thats what [lang] is, and thats why is doesn't fit the holy commons
> charter. Its a combination of useful utilities
> - too small to exist alone (one class)
> - that gain strength by being together (see some of the more unusual
> dependencies above)
> - encourage reuse and discourage cut and paste by offering more (I might cut
> and paste if I want one routine. I might depend if I want more than one. The
> broader range available increases reuse over cut and paste)
> - builds a viable community (not just counting committers, but users. The
> time and math packages are user suggestions. The util package is the useful
> parts of the dead community [util]. The functor package is the useful parts
> of the dead community [pattern].)
>
> Should we complain that the JDK contains stuff we don't use?
>
> Stephen
>
> ----- Original Message -----
> From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> >  Person ${p} suggests feature ${f} for component ${c}. Person ${q} insists
> > it belongs in [lang].
> >
> > and ${q} pulls from a very small set.
>
> and {q} = Stephen
> Rodney, please feel free to make it personal if thats what you believe.
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>