commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re:
Date Tue, 17 Dec 2002 04:26:08 GMT

On Tue, 17 Dec 2002 wrote:

> Henri Yandell <> wrote on 17/12/2002 12:31:41 PM:
> > 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 there's
> > nothing to say a project needs a certain size, you'd expect it to be a
> 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?

> > > > b) The [util] component is generally viewed as a 'dumping ground'
> for
> > > code
> > > > that doesn't fit in elsewhere, and might better be named 'misc' or
> > > > 'homeless'. The changes were designed to give [util] a chance of a
> > > release.
> > > How about moving it to commons rather than leaving it in sandbox?
> >
> > If it's ready, sure.
> Ready for?

Basically the above. If something lacks classes for a promotion from
sandbox, it suggests that it has a poor scope.

> > > <rant>
> > > I think Gump is the best tool we have for doing this, and we need to
> be
> > > nicer citizens.
> >
> > It's still stealthware to me, but that's my fault for not having found
> > where on the website it is linked in and checking it regularly.
> Emails on failures are sent to the -dev lists....

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

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..

> > > Having just been bitten by HttpClient deleting methods that have been
> > > available for months in CVS, I'm starting to question the current
> process
> > > of only deprecating if a method has been available in a 'release'
> product.
> >
> > Changing this means that we need a new layer for playing in. Forcing
> > developers to consider any checked in code to be in a release cycle will
> > seriously hamper creativity/play.
> Well, if the code has been untouched for months, I'd consider that we
> should at least deprecate things before deleting them. But this is no
> substitute for releasing.

I'm definitely in favour of releasing.

> > > Proposals:
> > > 1) Util should be moved to commons proper.
> >
> > -1
> Some explanation/technical justification please?

I don't think a project which lacks a stable core of classes should become
a Commons Project.

Thus the work at building some functionality into util with the identifier

> > > 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.
ii)  Does it have maturity. That is, has it spent some time in the sandbox
     while the developers use it, modified versions or extended versions
     in other projects.
iii) Does the project contain enough in the way of Unit Tests to show that
     the developers are serious about testing.
iv)  Is there a community, or is it a single developer. Does it have link
     to another project which will show a scope for its community growth.
v)   Does it have a webpage yet?

> > > Things to do:
> > > 1) Fix the ant and maven builds of both components so that they work.
> > > Having the gump build as the only one available, and the jars unable
> to be
> > > built from source is not acceptable.
> >
> > Will happily fix [util]'s ant and maven.
> <devils-advocate>
> Ok, but for what purpose. It's obvious no developers are building it from
> source on a regular basis. Given you'd rather not move it to commons, why
> don't we just delete it and move the code that's needed back where they
> 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 which
was not very stable at release time.
5) XmlUtils => Kill.
6) identifier/ => Find somewhere
7) GenerateUniqueId => Help commons-email with how to use identifier, or
commons-email contains this code

The death of Util might leave a gap. Should there be a loose structure for
holding 'usefulness'. ie) a waiting room. Or should this merely be a
series of patches etc in a holding space in Bugzilla/mail list.

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

View raw message