Technically, we shouldn't release until exiting commons-sandbox. I'll go
ahead and post a feeler to commons-dev about whether we are ready or not.
However, we could I suppose do a snapshot...?
Eric
-Original Message-
From: Corey Scott [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
I've started a new thread as I think it will be more useful as a
separate dialogue.
I've just tried Corey's unix test (and added the patched jar), and
have the same problems. Only very quickly so could be something that
i've overlooked. What i cant work out is how the dumbster tests passed
when i
Mark,
Maybe you can clear something up for me.. As far as I know, with JavaMail,
I still have to have *some* SMTP server running somewhere to send emails.
Are you saying that if I include smtp.jar, that acts as my SMTP server?
I don't have a problem factoring out the email smtp stuff into the
Eric
I don't have any issues working with dumbster, if indeed it works. Now
I've the dumbster source and I can replicate the same problem running
dumbster tests at least that helps identify the problem. Hopefully
they'll be a head version in cvs that can be patched.
When I get time I'll have a
Hi all,
While not calling for a formal vote, I wanted to gather feedback on any
issues that would bar allows commons-email to exit the sandbox. For those
of you not familiar with it, commons-email is an attempt to provide a
lightweight simple library for sending emails using the JavaMail
Okay..
I just got a fresh src of dumbster changed the port to 2500 and the
port 80 test to 2580 and it passes its own tests..
Not sure why it stopped working after my tests yesterday, i must have
messed with something i shouldn't have.
Lets see how i get on with the commons email tests..
On
olegk 2004/11/04 04:08:54
Modified:httpclient/src/test/org/apache/commons/httpclient
HttpClientTestBase.java
Log:
Disable use proxy flag for now
Revision ChangesPath
1.6 +5 -7
In addition to this (and to post to this list, what we have been
discussion privately). I have added a method to the dumbster which
takes a server socket as an input instead of a port number. The
advantage of this is that you can create the server socket using:
ServerSocket newSocket = new
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=32007.
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=32007.
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=30973.
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=32007.
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=31934.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-betwixt *no longer* has an issue.
The current state of this project is
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=32061.
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=32061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-betwixt *no longer* has an issue.
The current state of this project is
As far as I know I dont use smtp.jar at all? Weird
Its not the project file, there is no lib dir. Have i missed something?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Is this a OSX only thing? (I have tested WinXp and Redhat only)
-Corey
On 4 Nov 2004 16:13:36 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
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=32061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
No its confusion over how the mailapi is distributed.
You can have separte smtp.jat and mailapi or have all in one
(including pop and imap stuff).
The lighter way would be mailapi and smtp but none of the rest.
Mark
On Fri, 5 Nov 2004 02:34:52 +0800, Corey Scott [EMAIL PROTECTED] wrote:
Is
My only concern is checking out a copy and building and the tests
working, not so much for me but new users who could contribute. If
your dumbster patch cant be downloaded via maven then i don't mind
what happens, it was just a fillin and a start to tidying the unit
tests a bit.
On 4 Nov 2004
Main criteria are community and readiness for 1.0. Getting a 1.0 immediately
after promotion is actually really quite important.
Stephen
- Original Message -
From: Eric Pugh [EMAIL PROTECTED]
While not calling for a formal vote, I wanted to gather feedback on any
issues that would bar
olegk 2004/11/04 11:40:51
Modified:httpclient/src/test/org/apache/commons/httpclient/server
ErrorResponse.java HttpServiceHandler.java
ResponseWriter.java SimpleHttpServer.java
SimpleHttpServerConnection.java
I think on that front, we are ready. We are tiding up a unit test and
figuring out the best ant build script. So, if we move out of sandbox, I
think 1.0 would be days away from being VOTE'd on...
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Thursday,
On Thu, 4 Nov 2004 21:48:00 +0100, Eric Pugh [EMAIL PROTECTED] wrote:
I think on that front, we are ready. We are tiding up a unit test and
figuring out the best ant build script. So, if we move out of sandbox, I
think 1.0 would be days away from being VOTE'd on...
I probably missed some
It tanks on the download of the javamail jars. I am thinking of just
putting a /lib/javamail.jar and then having maven jar override map it, and
hopefully the Ant plugin will pick it up, or just tweak the plugin
afterwords to point to it.
Eric
-Original Message-
From: Martin Cooper
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=32068.
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=32068.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
rdonkin 2004/11/04 14:55:08
jakarta-commons/logging/optional - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 14:59:02
Modified:logging build.xml
logging/src/conf MANIFEST.MF
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when unit testing. Issue
#27663.
rdonkin 2004/11/04 15:00:04
Added: logging/optional build.xml
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when unit testing. Issue
#27663. Contributed by Joerg Schaible.
rdonkin 2004/11/04 15:00:19
Added: logging/optional project.xml
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when unit testing. Issue
#27663. Contributed by Joerg Schaible.
rdonkin 2004/11/04 15:00:36
Added: logging/optional .cvsignore
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when unit testing. Issue
#27663. Contributed by Joerg Schaible.
rdonkin 2004/11/04 15:00:44
jakarta-commons/logging/optional/src - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:00:51
jakarta-commons/logging/optional/src/java - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:01:05
jakarta-commons/logging/optional/src/java/org/apache - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:01:12
jakarta-commons/logging/optional/src/java/org/apache/commons - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:01:25
jakarta-commons/logging/optional/src/java/org/apache/commons/logging/impl - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:01:19
jakarta-commons/logging/optional/src/java/org/apache/commons/logging - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:01:39
Added: logging/optional/src/java/org/apache/commons/logging/impl
MemoryLog.java
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when
rdonkin 2004/11/04 15:01:48
jakarta-commons/logging/optional/src/conf - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:01:59
Added: logging/optional/src/conf MANIFEST.MF
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when unit testing. Issue
#27663. Contributed by Joerg Schaible.
rdonkin 2004/11/04 15:02:08
jakarta-commons/logging/optional/src/test - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:02:14
jakarta-commons/logging/optional/src/test/org - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:02:21
jakarta-commons/logging/optional/src/test/org/apache - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:02:28
jakarta-commons/logging/optional/src/test/org/apache/commons - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:02:34
jakarta-commons/logging/optional/src/test/org/apache/commons/logging - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:02:53
jakarta-commons/logging/optional/src/test/org/apache/commons/logging/impl - New
directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/11/04 15:03:07
Added: logging/optional/src/test/org/apache/commons/logging/impl
MemoryLogTest.java
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use
rdonkin 2004/11/04 15:03:59
Added: logging/optional/src/test/org/apache/commons/logging
TestAll.java
Log:
Added new optional subcomponent consisting of non-core implementations. Initial
contents MemoryLog, a log implementation intended for use when unit
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=27663.
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=32073.
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=32073.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
Although I've marked the subject with [collections], I guess this is
targeted at anyone who has an interest in a Java 5.0 port of any jakarta
project. I'm slowly chipping away at a Java 5.0 port of
commons-collections. As I've been generifying the original collections
classes, I've found
It is an accepted usage pattern that assertions are not to be used to
validate method parameters if they are part of the public interface.
They are properly used to check parameters passed to private members
though, but nothing a calling client might send in (where a client isn't
another part
The main reason not to use assertions is that they can be disabled at
runtime, rendering them fairly useless IMO. Personally, I would remove
the null parameter checking entirely and let the code throw a NPE. The
caller will see their offending method in the stack trace.
David
--- Chris Lambrou
On Thu, 4 Nov 2004 18:19:32 -0800 (PST), David Graham
[EMAIL PROTECTED] wrote:
The main reason not to use assertions is that they can be disabled at
runtime, rendering them fairly useless IMO. Personally, I would remove
the null parameter checking entirely and let the code throw a NPE. The
David Graham wrote:
The main reason not to use assertions is that they can be disabled at
runtime, rendering them fairly useless IMO.
I think this was a fundamental goal of assertions. I imagine that the
idea is to enable assertions during heavy development time, and disable
them once the code
59 matches
Mail list logo
