Fair enough. Sounds like a worthwhile idea. Thanks for the further explaination and for helping me with the submission.
Tom -----Original Message----- From: Daniel F. Savarese [mailto:[EMAIL PROTECTED] Sent: Saturday, April 24, 2004 3:24 PM To: ORO Developers List Subject: Re: Version file for oro... In message <[EMAIL PROTECTED]> , "Thomas Mitchell, Jr." writes: > About your tweak. Are you saying you would like users to be >able to create a Version class so they can create their own version of ><something>, but in the Jakarta format? That sounds obscure, but >flexible, and potentially dangerous. Even so, that I would vote for. Suppose a couple of projects decide that a Version class or interface is a handy thing for reasons similar to the one that motivated you. It would be convenient for them to use the same class or interface, so you could perform some dynamic checks like if(oroVersion.getMajorVersion() < 2) { abort("FOO requires ORO version 3.0 or higher\n"); } Or let's say you have an automated regression test suite that checks for changes in behavior between successive versions of software. It's handy to have the version be an instantiable object instead of a singleton with static methods. That way you can collect all of the versions and test results. The interface (I'm thinking it should be an interface now) can be read only and doesn't have to expose any setter methods. A default implementation could have protected setter methods. The open question I see is if one is to build a generic version facility, how do you query it generically? The best I can figure is to settle on a convention of placing a class named Version (different from the generic org.apache.version.Version interface) in the top level package (in our case org.apache.oro.Version) with a static getVersion() method that returns an org.apache.version.Version instance. >projects, so please excuse my ignorance. I would like to make sure >users don't hang themselves somehow. From a user perspective, version >information is generally query only; a one-way street. From an AP >perspective, creating a version with the Jakarta format may have some >use. As long as the shipped products can have clearly defined lines >between their version getter and the generic version creator (so to >speak), I think it's a great idea. Clear javadoc will help. Yes, I think we're on the same page. The idea is to keep the version getter and version creator separate. I actually have a need for a simple versioning API for a research project I'm working on. I have these objects that implement atomic pieces of functionality that are stitched together dynamically. If one of the objects fails in some way, I want to be able to revert to a previous version of the object. To do this in a general way, I need to be able to represent version information. Anyway, I think we can work on the version stuff here and then move it to either Jakarta Commons or Apache Commons as a simple package. I checked Ant and Maven and couldn't find anything comparable, but I couldn't find where the repository project is tucked away, so I don't know if they have something. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
