On the general topic of Java packaging and not to consider until the far 3.0 future ;-)
I think that we have a bit of package inflation already. From my POV, commons-lang extends java.lang and all of its stuff should just go in o.a.c.lang. But that's just me. I think that when you consider that packages are namespaces, I do not think that we need to keep all of what now makes up lang in separate namespaces. Just as an example, I find the use of a lang.builder package an odd choice rather than putting it all in lang. What do all the builder classes have in common? The only thing I can think of is that they provide the same kind of implementations to provide their services. Hardly worth a separate namespace, IMHO again. Gary > -----Original Message----- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Monday, August 18, 2003 00:06 > To: Jakarta Commons Developers List > Subject: Re: UUID Reuse proposal > > Tim Reilly wrote: > > Thanks for the positive response to adapting a UUID class in commons > lang. > > [The Axis list has responded with favoring option 2 which is basically > to > > not make changes at this time, but has no problem with use of the UUID > code > > from Axis in the commons.] > > I'm looking for direction on next steps - I believe after answering the > > following questions; I would create an enhancement in bugzilla and > attach > > patches or sources? > > Yes. I would start by patching IdentifierUtils (see below) to add some > additional methods, assuming that there are no objections to this > approach. > > > > > I think at this time there are two questions to resolve: > > > > ~1) Where to place the UUID code. > > I personally prefer a package and separate classes as Phil Steitz > suggests: > > " > > > >>I do like the idea of lang providing a home for "IdentifierUtils" > suitably > >>named and packaged. There are really multiple types here: > >> > >>* UUID (pseudo) standard, non-random, non-secure > >>* Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) > >>* Random, "secure", not guaranteed unique (e.g. Tomcat session IDs) > >>* Part random, "secure", guaranteed unique (what Tomcat really needs ;-) > >>* Bounded sequential(e.g. Betwixt's io identifiers) > >>* Cyclic" > > > > > > I believe the alternative is to add the UUID code to the existing > > IdentifierUtils.java. > > > Sorry, I had forgotten about the existing IdentifierUtils. I would > suggest that all of the things above could be added there, at least to > start. > > > (As a user of the library I believe it would be much easier to locate > and so > > more valuable to have in a "suitably named package" of > IdentifierUtils.) > > > > ~2) Which UUID implementation to use: > > Tim Anderson suggested using: > > http://cvs.sourceforge.net/cgi- > bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se > > rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone > know > > if there are any issues with the license on this. It seems it would be > okay > > as long as this license information were included along with the apache > > license in the source. (Would we also need an additional UUID- > License.txt? > > I'm not sure how to interpret item 2 of license) The alternative is to > use > > the Axis UUID and add features such as those in Tyrex's later. If a real > > issue exists I could try contacting them so find a suitable solution. > > I don't know about the license, but as I said above, I like the tyrex > impl better. In any case, making the implementation threadsafe would be > a good idea, as would (IMHO) allowing the node ID to be read from a > properties file. I would also be interested in others' opinions on the > value of the UUID "standard", especially minus the MAC address. > > Phil > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
