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:[email protected]] Sent: Friday, December 19, 2008 10:41 AM To: [email protected] 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:[email protected]] > Sent: Friday, December 19, 2008 7:21 AM > To: [email protected] > 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 > > >
