Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ECC1DCE.9080308@gmail.com>
References: <4ECC0A1E.2060100@gmail.com>
	<jah2j9$nea$1@dough.gmane.org>
	<4ECC1DCE.9080308@gmail.com>
Date: Tue, 22 Nov 2011 14:27:42 -0800
Message-ID: 
 <CAEk_X4ZcjVgis+eJx0NMQHuZWvxWsv56YkGSOr2CrLRy7futow@mail.gmail.com>
Subject: Re: [VOTE] Promote [id] to Commons proper
From: "ralph.goers @dslextreme.com" <ralph.goers@dslextreme.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001485ec1126cc156804b25a4fa7

--001485ec1126cc156804b25a4fa7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is precisely why this vote is premature. As I said, without having
looked at the code it is hard for me to understand why UUID stuff would be
so complicated that it shouldn't be part of lang.  The single class I
referenced earlier that I added to Log4j, with perhaps a couple of other
methods to create slightly different variants, would all I would expect to
need.

Ralph

On Tue, Nov 22, 2011 at 2:10 PM, Phil Steitz <phil.steitz@gmail.com> wrote:

> On 11/22/11 2:01 PM, J=F6rg Schaible wrote:
>
> >
> > Sorry, before we do not define the use cases, it does simply not make
> sense.
> >
> > SANDBOX-53 explains that commons-id is supposed to be added to
> jre/lib/ext,
> > because of the special requirements for generating UUIDs. Since it has
> > runtime deps to ant, commons-discovery and commons-logging-api they wou=
ld
> > have to be added there, too. So, you mean anythings works quite well wi=
th
> > these libraries in the system classpath??? C'mon! One commons-logging
> > classpath fiasko is enough.
>
> I would say figuring this out is part of getting it into releasable
> state.  What, if any, dependencies it ends up with can be discussed
> as we work towards a release.  There is a lot more to be done /
> considered in the UUID code as well.  Promoting just means we intend
> to work toward a release, possibly with some things removed from the
> current code.
>
> > That's why I proposed to create a uuid component only with no further
> > dependencies that *can* be used actually in such a scenario. The rest o=
f
> id
> > might move to lang or stay on its own.
>
> IIRC, the non-UUID stuff has no external dependencies, so I see no
> reason to have to split them out.  I think the API (which includes
> the UUID stuff as one impl) is generally useful and, pretty much for
> the reasons given when it was pulled out of [lang] originally, makes
> sense as an independent component.  There are some useful non-UUID
> generators in there.  Why not just keep the component as [id]?
>
> Phil
>
>

--001485ec1126cc156804b25a4fa7--