On 11/22/11 2:01 PM, Jörg Schaible wrote: > Hi Phil, > > Phil Steitz wrote: > >> We seem to have some renewed interest in [id] and some volunteers >> willing to step up to help get it into a releasable state. So I >> would like to propose that we promote [id] to commons proper. >> >> Votes, please. This vote will close in 72 hours, or if there are >> violent objections before then. >> >> Phil >> >> [ ] +1 Promote [id] to Commons proper >> [ ] +0 OK, but... >> [ ] -0 Not thrilled about this >> [ ] -1 We should not do this > -1 > > 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. Phil > > 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 > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
