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 06:19:29 GMT


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

> Henri Yandell <bayard@generationjava.com> wrote on 17/12/2002 03:26:08 PM:
> > On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> >
> > > Henri Yandell <bayard@generationjava.com> wrote on 17/12/2002 12:31:41
> PM:


> > I do have one request here. The emails do not specify who should be
> talked
> > to in an effort to fix the build.
>
> ? The -dev list gets emailed. The developer(s) should be listening.
>
> > 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..
>
> Then you would have replied to me :) The nag has me as the from address.

Sounds good. Where are the nag addresses documented? [Just so I can know
who the Nag person is for projects I work on, it's something I'm happy to
do, so if they're notkeen on it I can volunteer]

> [snip]
> > > > -1
> > >
> > > Some explanation/technical justification please?
> >
> > I don't think a project which lacks a stable core of classes should
> become
> > a Commons Project.
>
> Core set of classes be damned. It's more important to have developers
> working together on making things better.

Sure, but [util] has neither :) If a project has developers working avidly
on it, I would expect a core set of classes pronto.

> > Thus the work at building some functionality into util with the
> identifier
> > sub-package.
> >
> > > > > 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.
> Who cares about javadoc if there isn't usage documentation. For a 'common'
> component, isn't that more important?

Definitely. http://www.flamefew.net/~hen/jakarta-tutorial.html hopefully
shows that I'm in agreement here, even if it's a slow process.

> > 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.
> Maybe the code's been used to death before getting into commons?

So it has maturity.

> > iii) Does the project contain enough in the way of Unit Tests to show
> that
> >      the developers are serious about testing.
> Is this a particular %age Code coverage?

If a number is needed. Really I just think it's a devotion to
professionalism that Apache demands. Having UTs is a definite show of
this.

> > 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?
> Web pages are easy to generate....and harder to keep up to date. Check
> http://jakarta.apache.org/commons/, it's got old components listed. Or
> http://jakarta.apache.org/commons/lang.html which has virtually no
> documentation on using the library. Which sort of defeats the purpose of
> making a reusable library....

Yep, criticism accepted. Not having a webpage though shows that the
project has not even begun to think about how to communicate to its future
users.

What are the old components on commons?

> [snip]
> > > <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.
> Yep.

Kay. I'll make a move for this to head in one of those directions. See if
people there are happy.

> > 2) Interpolator => Kill.
> > 3) StopWatch ?

This is the only thing in Util which really leaps out as util to me [which
is ironic as it's originally from a library of mine called test, though
I've seen it mentioned in books as well].

> > 4) WordWrapUtils => Lang's sandbox. It's a break off of StringUtils
> which
> > was not very stable at release time.
> Sounds like it belongs back in StringUtils.

Yeah, has crappy bugs that need rewriting. I have to do this for String
Taglib so it's fast climbing my todo list.

> > 5) XmlUtils => Kill.
> > 6) identifier/ => Find somewhere
> > 7) GenerateUniqueId => Help commons-email with how to use identifier, or
> > commons-email contains this code
> I've fixed commons-email to use identifier.

Are yourself or Jon satisified that the identifier code happily replaces
the GUId code, or should we aim to replace it?

> I suppose the hassle is the lack of direction about util. It seems to be a
> dumping ground, which, IMHO, aint such a good thing. I was under the vague
> impression it, like lang, was a collection of helpers to go with
> java.util.....

It's supposed to be, but think about it. Most of java.util is the
Collection API. util.Date/Calendar vanish off into Lang or other projects
as Date is really a special type. Similar for Currency if any of us were
coding to 1.4. Sub-project things like util.zip/util.jar are currently
hiding away in io.compress [need moving, I don't know to where]. So it's
no surprise that Jakarta Util is now pretty empty [once lang, and io, and
others left... in fact the old jakarta.util probably = the commons core
that Stephen and I talk about].

To go further [now I have javadoc open]:

Event stuff would be in BeanUtils.
Resource stuff is in Resources(?) or in some i18n/text package in the
future.

It pretty much ends up that Util = Random, and that's really a Math class.
So java.util is pointless, and jakarta.util is even more so pointless.

I wonder if the java.util API is a dumping ground between the JDK creators
when they can't agree :)

Hen


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