axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: UUID Reuse proposal
Date Fri, 15 Aug 2003 18:27:22 GMT
Same as Tom:

+1 on the idea of an Axis class being useful to others and getting
'promoted' to commons.
-1 to adding another jar file dependency to Axis.

-----Original Message-----
From: Tom Jordahl []
Sent: Friday, August 15, 2003 11:19 AM
To: ''
Subject: RE: UUID Reuse proposal

+1 on the idea of an Axis class being useful to others and getting
'promoted' to commons.
-1 to adding another jar file dependency to Axis.

My feeling would be: feel free to take the code and put it in commons, but
axis should just sit tight.

Tom Jordahl

-----Original Message-----
From: Steve Loughran []
Sent: Friday, August 15, 2003 1:40 PM
Subject: Re: UUID Reuse proposal

Tim Reilly wrote:
> I'd like to ask the axis developers to donate the java package
> org.apache.axis.components.uuid to the Jakarta commons.

UUID creation is an important thing in many places (POI?), so, yes, 
having a commons impl is a good thing.

The only worry I have is that it adds another core dependency to Axis, 
and that makes build, test & use of the system harder. We have lots of 
dependencies already, and, especially client-side, some people find this 
(and the resultant size of axis) an issue. I have just been busy writing 
a reflection based binding to commons-modeler, for example, so that if 
that jar is there we can auto-register parts for JMX management, but if 
it isnt, all still works.

> I'm cross-posting this message on both jakarta commons-dev list and
> list as commons could adopt this package and place somewhere sensible to
> commons. My suggestion would be as an addition to org.apache.commons.lang
> since the UUID is a special/complex type (aren't all classes, but
> you know what I'm saying.)
> I know not to cross-post but given the request it only makes sense. I
> realize the package has some basis on the similar package in the BSD
> licensed project. It doesn't make
> sense to include the UUIDGenFactory, which would remain in place (unless
> anyone has good ideas on making it more generic?)
> The reason for this request is that the package is nicely written (kudos
> the author(s)), and very useful in a number of applications. The Jetspeed
> developers can use this package; however it does not necessarily make
> for Jetspeed to create a dependency on the axis jar, solely to use this
> package. There are numerous other applications of UUID's that make it an
> ideal candidate for the Jakarta-commons, and I feel that donating/adopting
> this package within the commons fits nicely with the vision of the
> Other uses abound, for example struts could use the classes to guarantee a
> form is submitted only once. A search of brings back
> patterns that use guid/uuid.
> I'd be willing to send the patches to the Axis team if the commons
> committers are willing to adopt the package and Axis wishes the same.
> Basically this would be to depreciate
> org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
> org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
> "org.apache.axis.components.uuid.SimpleUUID" strings within the CVS. Or if
> there is a better way.. I'd be will to do whatever is agreed upon.
> Please consider this request; I'll keep an eye on each list and if both
> projects agree that would be great and we can proceed.
> A lesser alternative would be for jakarta-commons to adopt the package,
> axis makes no changes. This is the perhaps the lesser approach since reuse
> is not fully accomplished but if the Axis committers are reluctant then
> perhaps they could give their "okays" to the lesser approach, and
> jakarta-commons could still adopt the classes.
> For more information on UUID:
> Per javadoc comment -
> * A Universally Unique Identifier (UUID) is a 128 bit number generated
> * according to an algorithm that is guaranteed to be unique in time and
> space
> * from all other UUIDs. It consists of an IEEE 802 Internet Address and
> * various time stamps to ensure uniqueness. For a complete specification,
> * see
> Thank you for considering.
> -Tim Reilly

View raw message