> > So I'd like to propose the following: > > add a util package with the following structure + classes: > > > > [Package] o.a.c.id.util > > [Class] o.a.c.id.util.Bytes.java > > [Package] o.a.c.id.util.codec > > [Class] o.a.c.id.util.codec.BinaryDecoder.java > > [Class] o.a.c.id.util.codec.BinaryEncoder.java > > [Class] o.a.c.id.util.codec.Decoder.java > > [Class] o.a.c.id.util.codec.DecoderException.java > > [Class] o.a.c.id.util.codec.Encoder.java > > [Class] o.a.c.id.util.codec.EncoderException.java > > [Package] o.a.c.id.util.codec.binary > > [Class] o.a.c.id.util.codec.binary.Hex.java > > [Package] o.a.c.id.util.codec.binary.digest > > [Class] o.a.c.id.util.codec.digest.DigestUtils.java > >
From: "Phil Steitz" <[EMAIL PROTECTED]> > 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. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
