commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: GenerateUniqueId.java
Date Tue, 17 Dec 2002 01:31:41 GMT


On Tue, 17 Dec 2002 dion@multitask.com.au wrote:

> "Stephen Colebourne" <scolebourne@btopenworld.com> wrote on 17/12/2002
> 11:35:17 AM:
>
> [snip]
>
> > 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
> stable.
> > 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.

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.

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

> > c) Commons must have the right to make changes to code and manage its
> own
> > 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
> ground'
> > for other jakarta projects hoping to off-load maintainance, rather than
> a
> > 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.
> <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.

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

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

Why doesn't the user just depend on a tagged date and not HEAD?

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

-1

> 2) Email should be moved to commons proper.

+0 [assuming it is current and not out of date, and that it is ready
codewise]

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



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message