commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [id] util package
Date Mon, 31 May 2004 08:51:31 GMT
> > So I'd like to propose the following:
> > add a util package with the following structure + classes:
> >
> > [Package]
> > [Class]
> > [Package]
> > [Class]
> > [Class]
> > [Class]
> > [Class]
> > [Class]
> > [Class]
> > [Package]
> > [Class]
> > [Package]
> > [Class]
> >

From: "Phil Steitz" <>
> Given the number of [codec] classes involved, I would rather keep the
> dependency.

The question is whether you actually want these classes, or just part of the
code within. The exceptions certainly shouldn't be needed, nor the
Decoder/Encoder superclasses. And none of them should be part of the public
API of [id].

The issue here is whether, I as a user, can just come along and pick up the
library and not need to think about dependencies etc. If I just want an
incrementing number id, then why should I take codec? (I know you wouldn't
need to but that is basically too confusing to try to explain.)

So two solutions:
1) Create one package scoped utils class in [id] with just the relevant
methods on it.

2) Produce two multiple files - id-all, id-uuid and id-simple, the first two
having a codec dependency.

I'd suggest the first solution is preferable.

One way to try and picure this is to classify [id] in the bigger scheme of
things. [lang], [collections], [io] and [codec] are all low level APIs - no
dependencies. Hopefully [beanutils] will join the group soon. Then there is
a next level up, [betwixt], [digester], [jxpath], [validator] which do have
dependencies (also [oro], [regexp], [bcel]...). This is quite a big
difference in a library - and maybe if commons keeps growing, then these
could become two projects/mailing lists - eg. commons-base and commons-app.
Which group does [id] fit with? I'd suggest it should be the first.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message