You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oro-dev@jakarta.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2004/04/14 03:22:11 UTC
Re: Version file for oro...
In message <41...@MAIL01.bedford.progress.com>
, "Thomas Mitchell, Jr." writes:
> I was unsure if I am allowed to send attachments to the list, as
>I am new to the dev list, so I simply copied my version of this class
Text attachments should be fine.
> I'm not sure if I 'named' the various pieces of the version
>correctly, so please change to taste. This class can go in
>org.apache.oro or org.apache.oro.util. Also, the getFullVersion()
>method text should be changed to return a String more to your liking,
>maybe with a reference to the license? I'm kinda winging it here....
I think it looks fine. Since no one else has commented on
it, I'm inclined to just check it in. However, since I have some
tweaks in mind, I'd like to air them before acting on them. First,
how should we handle the convention some projects have, that ORO
mimicked, of doing an x.x.x-dev-1 release? Should we abandon
the -dev convention in favor of something else or just change
buildNumber to a string? Should we incorporate the notions of
beta and alpha with isBeta() and isAlpha() methods or isReleaseCandidate()
or isFinal() or isDevelopment()?
Now, my tweak. How do people feel about getting rid of the static
methods and members? How about we make Version a regular class
with constructor arguments that you fill in to define the version.
Then maybe we'd just implement an OROVersion class that had a static
final method:
Version getVersion()
that would return the version. And maybe we put Version in oro.util the
way Thomas initially suggested. Why would you want to do this? Well,
it allows other projects to use the Version class for their own purposes.
You could argue that a Version class should reside in Jakarta Commons. I
think it's okay if we keep it here and then move it into Commons later.
Something to look into is whether the maven or repository projects or
jakarta commons have version-related classes.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Groovy
Posted by "Mark F. Murphy" <ma...@tyrell.com>.
I didn't check.... but...
What regex is project Groovy using?
http://groovy.codehaus.org/
It's built into the language.
I haven't downloaded it yet... but I see it depends on JDK 1.4, so I
suspect it's not ORO.
:(
mark
--
---------------------------------------------------------------------------
Mark F. Murphy, Director Software Development <ma...@tyrell.com>
Tyrell Software Corp <http://www.tyrell.com>
---------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Re: Version file for oro...
Posted by "Mark F. Murphy" <ma...@tyrell.com>.
At 9:22 PM -0400 4/13/04, Daniel F. Savarese wrote:
>Then maybe we'd just implement an OROVersion class that had a static
>final method:
> Version getVersion()
Hmmmm....
Can we check to see if there's a more common way to do this?
I'd be concerned about returning yet another class with methods one
has to know.
Worse case I guess could be:
getVersion().toString()
As long as Version had a toString() that could be a standard output.
mark
--
---------------------------------------------------------------------------
Mark F. Murphy, Director Software Development <ma...@tyrell.com>
Tyrell Software Corp <http://www.tyrell.com>
---------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org