You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/08/23 03:13:57 UTC
[lang] 1.0 release foci (fwd)
Here's the document from a while back on a release focus. After the tiring
public/private debate and the surprise as to the nature of Commons, I'd
like to suggest that we think about a release again, with the focus on
getting the current functionality out as stabley possible.
1) Reflection: Could we put this off for 2.0?
2) Enum. This is in the main cvs now.
3) HashCodeUtils. This is now HashCodeBuilder.
4) ExceptionUtils. This is in CVS now.
5) StringUtils. There are some suggested additions to this to be
discussed, but not a lot.
6) NumberUtils. Some suggestion of extra functions for it, but nothing
really concrete yet. 2.0?
7) Util.CalendarUtils/*. Anything pressing in here or 2.0?
extra:
8) SystemUtils. Seems cool :)
9) CharSetUtils. Should this be there? I'd like it to be because:
i) It's been partly released.
ii) String Taglib is a user on it *grin and whistle*. Although this isn't
a biggie. If we remove it I just move it over to String Taglib and use it
there.
Hen
---------- Forwarded message ----------
Date: Wed, 14 Aug 2002 00:06:08 -0400 (EDT)
From: Henri Yandell <ba...@generationjava.com>
Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
To: Jakarta Commons Developers List <co...@jakarta.apache.org>
Subject: [lang] 1.0 release foci
1) Reflection code. This is still up in the air with ClassUtils waiting
in the wings. I need to commit ClassUtils into the top dir in sandbox.lang
so people can have easy access to it.
2) Enum. Stephen submitted his code ideas to the sandbox. Opinions are
needed etc.
3) HashCodeUtils. Stephen just submitted this class. Opinions desired. My
only one is whether developers are happy for us to make decisions for
them, like using 37 as the 'random primary number'. Hopefully therre's no
use case for a developer needing control over that.
4) ExceptionUtils. Some comments from Costin are directing us to the fact
that the exception sub-package needs enhancement. [Some work has been
commited on this, there are a lot of suggestions over the mail list that
need collating]
5) StringUtils. Prior to my emergency, I was looking into all String Utils
packages in the Jakarta CVS. I aim to continue that and continue to suck
anything useful out of them. In fact I want to find anything with 'Util'
or 'Helper' in the name, but that takes a little while :) [And of course
there's the public() to figure out now]
6) NumberRange. I looked into adding some operations from an Interval
class of mine [which came from a Lisp book a while back] and need to
email with the strategies to see if anyone agrees.
Part of this saw me add a min(double[]) and max(double[]) set of
methods to NumberUtils. Are these [and other primitives I guess?] of
interest?
7) Util.CalendarUtils. There was some suggestion that some time based code
might make its way into Lang. Am unsure where that all ended up, I know
CalendarUtils seemed to be on its way into Util for the time being. Any
other Util classes which are deemed of interest to Lang would be worth
considering now. It's mainly flotsam.
....
That's as far as I got on Sunday. Any other things?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Regarding printStackTrace() in ExceptionUtils, I ended up adding
methods for manipulating stack frames, rather than for printing them
to provides more flexibility for the user.
String getStackTrace(Throwable)
String[] getStackFrames(Throwable)
Supplying this API also side steps possible mis-matches in the
semantics of printStackTrace(). Since different Throwable
implementations may or may not implement printStackTrace() to print
the _entire_ stack trace (especially if their nested trace isn't
recognized by the impl as another link in the exception chain), we
would cause confusion by saying that an ExceptionUtils implementation
will always print the full trace of the entire exception chain. It's
possible that there's a way around this; if so, we can always add it
later, implementing it with the methods defined above.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:
> Show off.
Hah!
> I prefer it to any of mine [though I did think printStackTraces was kinda
> snazzy].
That wuz my favorite.
> On 22 Aug 2002, Daniel Rall wrote:
>
> > Heh. printFullStackTrace()?
> >
> > Henri Yandell <ba...@generationjava.com> writes:
> >
> > > First to mind is printDeepStackTrace. Something along the lines of a deep
> > > clone meaning. Or, printStackTraces. printStackedTraces.
> > > printNestedStackTraces. printAllStackTraces.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Henri Yandell <ba...@generationjava.com>.
Show off.
I prefer it to any of mine [though I did think printStackTraces was kinda
snazzy].
On 22 Aug 2002, Daniel Rall wrote:
> Heh. printFullStackTrace()?
>
> Henri Yandell <ba...@generationjava.com> writes:
>
> > First to mind is printDeepStackTrace. Something along the lines of a deep
> > clone meaning. Or, printStackTraces. printStackedTraces.
> > printNestedStackTraces. printAllStackTraces.
> >
> > erm.
> >
> > i admit, i've not got any good ideas :)
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Heh. printFullStackTrace()?
Henri Yandell <ba...@generationjava.com> writes:
> First to mind is printDeepStackTrace. Something along the lines of a deep
> clone meaning. Or, printStackTraces. printStackedTraces.
> printNestedStackTraces. printAllStackTraces.
>
> erm.
>
> i admit, i've not got any good ideas :)
>
> On 22 Aug 2002, Daniel Rall wrote:
>
> > Henri Yandell <ba...@generationjava.com> writes:
> >
> > > 4) ExceptionUtils. This is in CVS now.
> >
> > All proposed additions and changes which I am aware of are in this
> > with the exception (ha ha ha) of the printStackTrace() method Stephen
> > suggested adding (I already implemented the rest of his suggestions).
> > I left this one out because I wasn't sure that name makes it clear
> > enough that it will print the stack trace for the entire exception
> > chain. Suggestions appreciated.
> >
> > Costin, if you have other suggestions for this which would make it
> > more palatable for your use cases, please let me know.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Henri Yandell <ba...@generationjava.com>.
First to mind is printDeepStackTrace. Something along the lines of a deep
clone meaning. Or, printStackTraces. printStackedTraces.
printNestedStackTraces. printAllStackTraces.
erm.
i admit, i've not got any good ideas :)
On 22 Aug 2002, Daniel Rall wrote:
> Henri Yandell <ba...@generationjava.com> writes:
>
> > 4) ExceptionUtils. This is in CVS now.
>
> All proposed additions and changes which I am aware of are in this
> with the exception (ha ha ha) of the printStackTrace() method Stephen
> suggested adding (I already implemented the rest of his suggestions).
> I left this one out because I wasn't sure that name makes it clear
> enough that it will print the stack trace for the entire exception
> chain. Suggestions appreciated.
>
> Costin, if you have other suggestions for this which would make it
> more palatable for your use cases, please let me know.
>
> - Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:
> 4) ExceptionUtils. This is in CVS now.
All proposed additions and changes which I am aware of are in this
with the exception (ha ha ha) of the printStackTrace() method Stephen
suggested adding (I already implemented the rest of his suggestions).
I left this one out because I wasn't sure that name makes it clear
enough that it will print the stack trace for the entire exception
chain. Suggestions appreciated.
Costin, if you have other suggestions for this which would make it
more palatable for your use cases, please let me know.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> From: "Henri Yandell" <ba...@generationjava.com>
> > I've put the Maven site up at:
> >
> > http://www.generationjava.com/maven/jakarta-commons/lang/index.html
> >
> > if it's of use to anyone. Reading the javadoc through that is often more
> > fun/easier.
>
> I've addressed some of the checkstyle points. However, some checkstyle
> issues don't seem like problems:
> 1) Line length - even the CVS $Id$ lines are longer than 80 chars. I'd
> propose a 120 char limit
Ugh, please no -- that makes doing work in a term a PITA. I propose
removing the $Id: $ markers entirely; they really make diffing and
merging between branches a bitch (fancy options be damned).
> 2) Throwing runtime exceptions - I guess this is a bug/feature of
> checkstyle. As far as I know, a runtime exception shouldn't be declared in
> the throws clause but should be in the javadoc
Unchecked (e.g. RuntimeExceptions) should definitely be in the JavaDoc
as @throws.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by di...@multitask.com.au.
"Stephen Colebourne" <sc...@btopenworld.com> wrote on 31/08/2002
09:25:28 PM:
> From: "Henri Yandell" <ba...@generationjava.com>
> > I've put the Maven site up at:
> >
> > http://www.generationjava.com/maven/jakarta-commons/lang/index.html
> >
> > if it's of use to anyone. Reading the javadoc through that is often
more
> > fun/easier.
>
> I've addressed some of the checkstyle points. However, some checkstyle
> issues don't seem like problems:
> 1) Line length - even the CVS $Id$ lines are longer than 80 chars. I'd
> propose a 120 char limit
> 2) Throwing runtime exceptions - I guess this is a bug/feature of
> checkstyle. As far as I know, a runtime exception shouldn't be declared
in
> the throws clause but should be in the javadoc
I think this is 'fixed' in checkstyle 2.3. About time we upgraded
maven.....
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> I've put the Maven site up at:
>
> http://www.generationjava.com/maven/jakarta-commons/lang/index.html
>
> if it's of use to anyone. Reading the javadoc through that is often more
> fun/easier.
I've addressed some of the checkstyle points. However, some checkstyle
issues don't seem like problems:
1) Line length - even the CVS $Id$ lines are longer than 80 chars. I'd
propose a 120 char limit
2) Throwing runtime exceptions - I guess this is a bug/feature of
checkstyle. As far as I know, a runtime exception shouldn't be declared in
the throws clause but should be in the javadoc
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Henri Yandell <ba...@generationjava.com>.
[Sorry, got distracted by the world I don't see through a laptop,
summarising again:]
>From the quietness I'm guessing that we're pretty much there with the
following:
> 1.0
> > > 2) Enum. This is in the main cvs now.
> > > 3) HashCodeUtils. This is now HashCodeBuilder.
> > > 4) ExceptionUtils. This is in CVS now.
> 1.x?
> > > 8) SystemUtils. Now ready.
as additions to the released beta. Stephen's action items in the
STATUS.html are very useful. Just two [exception tests] that leap to mind
as being 1.0?
I've put the Maven site up at:
http://www.generationjava.com/maven/jakarta-commons/lang/index.html
if it's of use to anyone. Reading the javadoc through that is often more
fun/easier.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Henri Yandell <ba...@generationjava.com>.
So, separating these out we have functionality of:
1.0
> > 2) Enum. This is in the main cvs now.
> > 3) HashCodeUtils. This is now HashCodeBuilder.
> > 4) ExceptionUtils. This is in CVS now.
2.0/1.x
> > 1) Reflection: Could we put this off for 2.0?
> > 5) StringUtils. There are some suggested additions to this to be
> > discussed, but not a lot.
> > 6) NumberUtils. Some suggestion of extra functions for it, but nothing
> > really concrete yet. 2.0?
> > 7) Util.CalendarUtils/*. Anything pressing in here or 2.0?
> > 8) SystemUtils. Seems cool :)
> > 9) CharSetUtils. Should this be there?
10) A million ideas in our heads. I suggest that these are either
commited to the Lang sandbox or to Utils [depending on just how nicely
they look in Lang]. Thigns like, new methods for NumberUtils or
StringUtils could also feasibly be placed in a temporary class in the
sandbox.
Then, once the functionalities for 1.0 are stable, we have the usual
suspects to round up. Unit testing for the 1.0's, javadoc, webpage
grumblings, release.txt creating, release-manager accepting, release
voting, release doing.
I might be missing something there or have something in the wrong order.
I'm not sure when the proper time is to decide who will manage the
release.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:
> > The only problem we face ATM is SystemUtils. We either
> > 1) Remove it to the sandbox
> > 2) Remove the controversial parts to the sandbox
> >
> > I favour (1) to get the release out.
>
> If the release manager is unable to make a release based on only some of
> the classes, and I think it could be quite tricky, then I favour 1 too.
It's easy enough to exclude that single class from the build (in
build.xml) when we cut the release. I like this option because it
doesn't take the code out of component's source (only its binary), and
still produces a source component which CVS-taggable and reproducable.
If this is acceptable, I'd be happy to do this when we wish to cut the
release (and handle the associated CVS operations).
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 23 Aug 2002, Stephen Colebourne wrote:
> From: "Henri Yandell" <ba...@generationjava.com>
> > 1) Reflection: Could we put this off for 2.0?
> > 2) Enum. This is in the main cvs now.
> > 3) HashCodeUtils. This is now HashCodeBuilder.
> > 4) ExceptionUtils. This is in CVS now.
> > 5) StringUtils. There are some suggested additions to this to be
> > discussed, but not a lot.
> > 6) NumberUtils. Some suggestion of extra functions for it, but nothing
> > really concrete yet. 2.0?
> > 7) Util.CalendarUtils/*. Anything pressing in here or 2.0?
> > 8) SystemUtils. Seems cool :)
> > 9) CharSetUtils. Should this be there?
>
> I have some more ideas for classes (ToStringBuilder, EqualsBuilder,
> CompareToBuilder) and fields NullObject - but these can wait for later
> discussion.
+1 on ToStringBuilder. Maybe. I was thinking of a generic thing which
could toString arrays and the like nicely.
I've also got a Notifier idea I'd like to move in at some point [makes
Event/Listener pattern easy. Might not be a Lang thing].
>
> The only problem we face ATM is SystemUtils. We either
> 1) Remove it to the sandbox
> 2) Remove the controversial parts to the sandbox
>
> I favour (1) to get the release out.
If the release manager is unable to make a release based on only some of
the classes, and I think it could be quite tricky, then I favour 1 too.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] 1.0 release foci (fwd)
Posted by Steve Downey <st...@netfolio.com>.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Friday, August 23, 2002 1:51 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] 1.0 release foci (fwd)
>
>
>
> The only problem we face ATM is SystemUtils. We either
> 1) Remove it to the sandbox
> 2) Remove the controversial parts to the sandbox
>
> I favour (1) to get the release out.
Tag a branch and release off the branch. If SystemUtils is deleted from this
release, it can be continued to be worked on in the main branch. It's good
engineering practice, as it prevents accidental changes or additions between
an RC and final release.
The downside is double checkins for bug fixes.
Moving a project back and forth from commons and commons-sandbox is and will
be confusing.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> 1) Reflection: Could we put this off for 2.0?
> 2) Enum. This is in the main cvs now.
> 3) HashCodeUtils. This is now HashCodeBuilder.
> 4) ExceptionUtils. This is in CVS now.
> 5) StringUtils. There are some suggested additions to this to be
> discussed, but not a lot.
> 6) NumberUtils. Some suggestion of extra functions for it, but nothing
> really concrete yet. 2.0?
> 7) Util.CalendarUtils/*. Anything pressing in here or 2.0?
> 8) SystemUtils. Seems cool :)
> 9) CharSetUtils. Should this be there?
I have some more ideas for classes (ToStringBuilder, EqualsBuilder,
CompareToBuilder) and fields NullObject - but these can wait for later
discussion.
The only problem we face ATM is SystemUtils. We either
1) Remove it to the sandbox
2) Remove the controversial parts to the sandbox
I favour (1) to get the release out.
Stephen
> Hen
>
> ---------- Forwarded message ----------
> Date: Wed, 14 Aug 2002 00:06:08 -0400 (EDT)
> From: Henri Yandell <ba...@generationjava.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [lang] 1.0 release foci
>
>
> 1) Reflection code. This is still up in the air with ClassUtils waiting
> in the wings. I need to commit ClassUtils into the top dir in sandbox.lang
> so people can have easy access to it.
>
> 2) Enum. Stephen submitted his code ideas to the sandbox. Opinions are
> needed etc.
>
> 3) HashCodeUtils. Stephen just submitted this class. Opinions desired. My
> only one is whether developers are happy for us to make decisions for
> them, like using 37 as the 'random primary number'. Hopefully therre's no
> use case for a developer needing control over that.
>
> 4) ExceptionUtils. Some comments from Costin are directing us to the fact
> that the exception sub-package needs enhancement. [Some work has been
> commited on this, there are a lot of suggestions over the mail list that
> need collating]
>
> 5) StringUtils. Prior to my emergency, I was looking into all String Utils
> packages in the Jakarta CVS. I aim to continue that and continue to suck
> anything useful out of them. In fact I want to find anything with 'Util'
> or 'Helper' in the name, but that takes a little while :) [And of course
> there's the public() to figure out now]
>
> 6) NumberRange. I looked into adding some operations from an Interval
> class of mine [which came from a Lisp book a while back] and need to
> email with the strategies to see if anyone agrees.
> Part of this saw me add a min(double[]) and max(double[]) set of
> methods to NumberUtils. Are these [and other primitives I guess?] of
> interest?
>
> 7) Util.CalendarUtils. There was some suggestion that some time based code
> might make its way into Lang. Am unsure where that all ended up, I know
> CalendarUtils seemed to be on its way into Util for the time being. Any
> other Util classes which are deemed of interest to Lang would be worth
> considering now. It's mainly flotsam.
>
> ....
>
> That's as far as I got on Sunday. Any other things?
>
> Hen
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] 1.0 release foci (fwd)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, August 23, 2002, at 02:13 AM, Henri Yandell wrote:
<snip>
> 1) Reflection: Could we put this off for 2.0?
no point in postponing the 1.0 release for this but it could quite easily
be targeted for a 1.1 release.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>