commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ralph.goers @dslextreme.com" <ralph.go...@dslextreme.com>
Subject Re: [VOTE] Promote [id] to Commons proper
Date Tue, 22 Nov 2011 22:27:42 GMT
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örg 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 would
> > have to be added there, too. So, you mean anythings works quite well with
> > 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 of
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message