commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re:
Date Tue, 17 Dec 2002 01:24:26 GMT
"Stephen Colebourne" <> wrote on 17/12/2002 
11:35:17 AM:


> In broader terms however:
> a) The status of both the [util] and [email] components within
> jakarta-commons-sandbox is that of unreleased code, no matter how 
> Deprecation is not required.
Unfortunate, but true. It's the community part that's missing here.

I'd like to see a move of both of these components to commons.

> b) The [util] component is generally viewed as a 'dumping ground' for 
> 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 
How about moving it to commons rather than leaving it in sandbox?

> c) Commons must have the right to make changes to code and manage its 
> releases and components. This should apply whether it is code written
> specifically for commons, or donated to commons from another jakarta
> project. If this is not the case then commons is simply a 'dumping 
> for other jakarta projects hoping to off-load maintainance, rather than 
> vibrant community in its own right.
Agreed, but like all code that is to be used and reused, we must consider 
the users of the software.
I think Gump is the best tool we have for doing this, and we need to be 
nicer citizens.

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.

I would like deprecation to happen for a time period before deletion, if 
the code was not part of a release, especially in Commons, where the code 
is by design meant to be used by others. And the code base can be stable, 
without a release for a long time.

1) Util should be moved to commons proper.
2) Email should be moved to commons proper.

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.


dIon Gillard, Multitask Consulting

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

View raw message