You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2011/11/22 21:46:22 UTC
[VOTE] Promote [id] to Commons proper
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Promote [id] to Commons proper
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
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 <ph...@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
>
>
Re: [VOTE] Promote [id] to Commons proper
Posted by Phil Steitz <ph...@gmail.com>.
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Promote [id] to Commons proper
Posted by Jörg Schaible <jo...@gmx.de>.
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.
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.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[DISCUSS] Re: [VOTE] Promote [id] to Commons proper
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
I think this vote is slightly premature. Jorg expressed a desire to strip
it of some things to move it into lang. I've not had a chance to look at
the id code to figure out what I'd like to do.
Ralph
On Tue, Nov 22, 2011 at 12:46 PM, Phil Steitz <ph...@gmail.com> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Cancelled [VOTE] Promote [id] to Commons proper
Posted by Phil Steitz <ph...@gmail.com>.
Seems there is not support to do this at this time.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Promote [id] to Commons proper
Posted by Adrian Cumiskey <ad...@gmail.com>.
+1 and happy to help.
On 22 November 2011 14:46, Phil Steitz <ph...@gmail.com> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Promote [id] to Commons proper
Posted by Davanum Srinivas <da...@gmail.com>.
+1 Promote [id] to Commons proper
On Tue, Nov 22, 2011 at 3:46 PM, Phil Steitz <ph...@gmail.com> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org