jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mitchell, Jr." <tmitc...@progress.com>
Subject RE: Version file for oro...
Date Mon, 26 Apr 2004 16:54:22 GMT
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:dfs@savarese.org] 
Sent: Saturday, April 24, 2004 3:24 PM
To: ORO Developers List
Subject: Re: Version file for oro... 


In message
<418590005AFDB04DA77890F448295D432BFEDF@MAIL01.bedford.progress.com>
, "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: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org


Mime
View raw message