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