commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re:
Date Tue, 17 Dec 2002 05:22:11 GMT
Henri Yandell <> wrote on 17/12/2002 03:26:08 PM:
> On Tue, 17 Dec 2002 wrote:
> > Henri Yandell <> wrote on 17/12/2002 12:31:41 
> >
> > > On Tue, 17 Dec 2002 wrote:
> > > > I'd like to see a move of both of these components to commons.
> > >
> > > I'd like to see there actually be code in util worthy of a commons
> > > project. Currently it's a tiny smattering of classes and while 
> > > nothing to say a project needs a certain size, you'd expect it to be 
> > bit
> > > bigger.
> >
> > So when does it become worthy? What's the criteria being applied here?
> Ought to have Unit Tests? More than just 4 or 5 odd classes? that case most of Ant would never have gotten going. It takes a 
while before reasonable unit testing is reached in most projects.

> I do have one request here. The emails do not specify who should be 
> to in an effort to fix the build.

? The -dev list gets emailed. The developer(s) should be listening.

> Do the Gump people listen to all the lists they build, is their a gump
> list? I'd normally expect to reply to the email..

Then you would have replied to me :) The nag has me as the from address.

> > > -1
> >
> > Some explanation/technical justification please?
> I don't think a project which lacks a stable core of classes should 
> a Commons Project.

Core set of classes be damned. It's more important to have developers 
working together on making things better.

> Thus the work at building some functionality into util with the 
> sub-package.
> > > > 2) Email should be moved to commons proper.
> > >
> > > +0 [assuming it is current and not out of date, and that it is ready
> > > codewise]
> >
> > Can you clarify what 'ready' is?
> i)   Does it have a suitable level of javadoc. Not enough for an actual
>      release, but the bare minimum.
Who cares about javadoc if there isn't usage documentation. For a 'common' 
component, isn't that more important?

> ii)  Does it have maturity. That is, has it spent some time in the 
>      while the developers use it, modified versions or extended versions
>      in other projects.
Maybe the code's been used to death before getting into commons?

> iii) Does the project contain enough in the way of Unit Tests to show 
>      the developers are serious about testing.
Is this a particular %age Code coverage?

> iv)  Is there a community, or is it a single developer. Does it have 
>      to another project which will show a scope for its community 
> v)   Does it have a webpage yet?
Web pages are easy to generate....and harder to keep up to date. Check, it's got old components listed. Or which has virtually no 
documentation on using the library. Which sort of defeats the purpose of 
making a reusable library....

> > <devils-advocate>
> > Ok, but for what purpose. It's obvious no developers are building it 
> > source on a regular basis. Given you'd rather not move it to commons, 
> > don't we just delete it and move the code that's needed back where 
> > came from?
> > </devils-advocate>
> Definitely a good view. It seems there are two options, kill it or find
> functionality for it.
> I'd say there are 7 bits in there:
> 1) BitField  => Collections possibly. or Lang.
> 2) Interpolator => Kill.
> 3) StopWatch ?
> 4) WordWrapUtils => Lang's sandbox. It's a break off of StringUtils 
> was not very stable at release time.
Sounds like it belongs back in StringUtils.

> 5) XmlUtils => Kill.
> 6) identifier/ => Find somewhere
> 7) GenerateUniqueId => Help commons-email with how to use identifier, or
> commons-email contains this code
I've fixed commons-email to use identifier.

I suppose the hassle is the lack of direction about util. It seems to be a 
dumping ground, which, IMHO, aint such a good thing. I was under the vague 
impression it, like lang, was a collection of helpers to go with 

dIon Gillard, Multitask Consulting

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

View raw message