DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31017.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27523.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jfclere 2004/11/05 03:42:18
Modified:daemon/src/native/unix/native arguments.c
Log:
PR 30431: Thanks to Simon Roberts.
Revision ChangesPath
1.5 +4 -1 jakarta-commons/daemon/src/native/unix/native/arguments.c
Index: arguments.c
jfclere 2004/11/05 03:53:44
Added: daemon/src/native/unix CHANGES.txt
Log:
Prepare a 1.1 version ;-)
Revision ChangesPath
1.1 jakarta-commons/daemon/src/native/unix/CHANGES.txt
Index: CHANGES.txt
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30431.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28270.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jfclere 2004/11/05 04:08:10
Modified:daemon/src/samples SimpleDaemon.java SimpleDaemon.sh
Log:
Example to test PR 28270.
Revision ChangesPath
1.3 +9 -1 jakarta-commons/daemon/src/samples/SimpleDaemon.java
Index: SimpleDaemon.java
Hello
I'm the head of the open source project jptools. jptools contains several
frameworks like logging, parsing... (see http://jptools.sourceforge.net)
I wrote a JPToolsLogger which is compatible with the commons api. In this
mail the JPToolsLogger.java source is attached. I couldn't send
jfclere 2004/11/05 08:03:22
Modified:daemon/src/samples SimpleDaemon.java
Log:
Add a choice to test PR 30177.
Revision ChangesPath
1.4 +32 -5 jakarta-commons/daemon/src/samples/SimpleDaemon.java
Index: SimpleDaemon.java
jfclere 2004/11/05 08:53:11
Modified:daemon/src/native/unix/support apsupport.m4
Log:
Fix PR 30177.
Revision ChangesPath
1.6 +2 -2 jakarta-commons/daemon/src/native/unix/support/apsupport.m4
Index: apsupport.m4
Hi everyone,
I'm afraid I've found a bug in commons.collection.buffer.UnboundedFifoBuffer
If someone else already spotted it, sorry for that : I didn't find it in the bug list.
When removing an object from an UnboundedFifoBuffer via its iterator method,
I can get an
jfclere 2004/11/05 08:55:15
Modified:daemon/src/native/unix CHANGES.txt
Log:
Add entry for PR 30177.
Revision ChangesPath
1.2 +3 -2 jakarta-commons/daemon/src/native/unix/CHANGES.txt
Index: CHANGES.txt
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30177.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
This may not the time (or the place), but I am going to ask anyway.
It would seem that at the moment, all around the world, people are
doing the same work over and over. Particularly in regard to certain
packages/functions, this to me seems a little (well a lot) redundant.
Specifically, there
Hi,
The usual take on it is that the more options, the better. If there are
standards, that's great, but a lot of people think standards hinder
creativity. And if a product is really good it frequently becomes a
de-facto or actual.
So yeah, there are a lot of people doing similar work and
On Sat, 6 Nov 2004 02:21:09 +0800, Corey Scott [EMAIL PROTECTED] wrote:
This may not the time (or the place), but I am going to ask anyway.
It would seem that at the moment, all around the world, people are
doing the same work over and over. Particularly in regard to certain
The collections15 CVS looks good so far from a relatively quick look. The
main thing is to avoid the deprecated code and oddities like Bag (which you
seem to have done).
I wouldn't use assertions here, as you are trying to trap user input. (I've
never used assertions yet ;-)
Personally, I strive
I agree with Yoav. Diversity is good - if everyone got on one project,
everyone would have different ideas, and the tension would either tear
them apart or nothing would ever get done while they tried to agree.
Oh, and Jetspeed, Slide and Pluto probably all make components of a CMS
too (as
ggregory2004/11/05 17:27:59
Modified:lang/src/java/org/apache/commons/lang SystemUtils.java
Log:
Javadox typo.
Revision ChangesPath
1.37 +2 -2
jakarta-commons/lang/src/java/org/apache/commons/lang/SystemUtils.java
Index: SystemUtils.java
Hi,
As much as I'd like to replace all of the existing parameter checks with
assertions, I think that the current method of having explicit parameter
checking on all public methods will have to stand. Many thanks to you
all for your useful input. I thought that for the sake of completeness,
Thanks Martin, I hadnt seem Lenya before.
Thanks to everyone else who commented. I didnt want to sound
anti-diversity. I agree with you all diversity is good. I was trying
to suggest developing something based on standards so that integration
would be it usual nightmare.
Obviously CMS was a
21 matches
Mail list logo
