commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re:
Date Tue, 17 Dec 2002 03:17:46 GMT
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 
> bigger.

So when does it become worthy? What's the criteria being applied here?

> > > b) The [util] component is generally viewed as a 'dumping ground' 
> > 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?

> > <rant>
> > I think Gump is the best tool we have for doing this, and we need to 
> > 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....

> > Having just been bitten by HttpClient deleting methods that have been
> > available for months in CVS, I'm starting to question the current 
> > of only deprecating if a method has been available in a 'release' 
> 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 would like deprecation to happen for a time period before deletion, 
> > the code was not part of a release, especially in Commons, where the 
> > is by design meant to be used by others. And the code base can be 
> > without a release for a long time.
> > </rant>
> Why doesn't the user just depend on a tagged date and not HEAD?

Even if they do, they will still eventually be bitten when they go to 
upgrade. Gump is all about early warning.

> > Proposals:
> > 1) Util should be moved to commons proper.
> -1

Some explanation/technical justification please?

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

> > 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.
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?
dIon Gillard, Multitask Consulting

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

View raw message