Well, I guess a reason would be that users might want to use their own
methodology for creating a unique identifier. Perhaps within their
organization they have strict guidelines for GUID generation.
I guess it's a question of application flexibility versus code complexity.
In this case, I don't have an idea of how useful keeping the GUID generation
open is, but also, I don't think it complicates the code that much.
In essence, I think we're pulling hairs here. I would perhaps keep it in
for now and after we build a community around this release, we can inquire
about the usefulness of GUID generation flexibility and make a decision
then.
-----Original Message-----
From: Kurt T Stam [mailto:kurt.stam@gmail.com]
Sent: Friday, December 19, 2008 10:41 AM
To: juddi-dev@ws.apache.org
Subject: Re: UUIDGen in jUDDI v3
If there is no reason, then I'd like to remove them and the factory and
the config for it. Less to worry about is good in my book. The entire
enchilada would collapse to the line:
UUID.randomUUID();
I would like to achieve 100% unittest code coverage. Do I hear you
signing up for adding tests for nostalgia sake :)?
--Kurt
Jeff Faath wrote:
> Ah...for nostalgia? Actually, there's no harm in keeping them. If you
want
> to add an implementation of UUDIgen that uses the Java generator and make
> that the default, that's fine.
>
> -----Original Message-----
> From: Kurt T Stam [mailto:kurt.stam@gmail.com]
> Sent: Friday, December 19, 2008 7:21 AM
> To: juddi-dev@ws.apache.org
> Subject: UUIDGen in jUDDI v3
>
> Hi guys,
>
> Now that Java has it's own UUID generator do we still need the ones
> provided in the org.apache.juddi.uuidgen package? I'm thinking not, but
> if anybody has a good argument why we should keep the ones in there then
> speak up!
>
> --Kurt
>
>
>
|