commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: GenerateUniqueId.java
Date Tue, 17 Dec 2002 03:17:46 GMT
Henri Yandell <bayard@generationjava.com> wrote on 17/12/2002 12:31:41 PM:

> On Tue, 17 Dec 2002 dion@multitask.com.au 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?

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

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

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

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.
<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>
--
dIon Gillard, Multitask Consulting
Blog:      http://www.freeroller.net/page/dion/Weblog
Work:      http://www.multitask.com.au


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