I just checked out the 2.1 release of collections and realised that it is
not buildable with maven because there is no tagged parent file.
I'm guessing we need to tag the jakarta-commons/project.xml [and same in
sandbox if we ever actually tagged there] when we do a release.
Hen
Because I find it helps me get a grip on what has changed etc:
http://www.apache.org/~bayard/commons-collections/Commons-Collections-2.1-to-3.0/changes.html
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24966.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
--
-
Vote: Promote commons-io to commons proper
[ ] +1 I am in favor of the move, and will help support it
[ X ] +0 I am in favor of the move, but am unable to help support it
[ ] -0 I am not in favor of the move
[ ] -1 I
If you could put your refactorings in a branch, that would be very cool
(easier to merge from / to head). My time is limited too (I am moving in
a couple of weeks), but I'll see if I can find the time to get some
betwixt work done.
Maybe an update on IRC ?
Mvgr,
Martin
On Mon, 2004-01-05 at
In message [EMAIL PROTECTED], steve cohen writes:
1) deprecate listFiles() methods that take a FileEntryParser parameter.
2) reimplement listFiles() to do what getFileList(null) now does.
3) reimplement listFiles(String pathname) to do what getFileList(null,
pathname) now does.
4) rename
In message [EMAIL PROTECTED], Daniel F. Savar
ese writes:
I forgot to add that I think we need a beta release for 1.2 to give us
I also forgot to add that there's at least one pending code submission/patch
that we need to review and include before a 1.2 release. I believe it
was the NTP/SNTP
In message [EMAIL PROTECTED], steve cohen writes:
There's still one problem with deprecating FTPFileListParser.
The one method of this interface (parseFileList()) is used in the
VMSFTPEntryParser. There is an implementation here that is distinct from the
default one in FTPFileListParserImpl.
dfs 2004/01/06 10:52:56
Modified:net/src/java/org/apache/commons/net/ftp FTPClient.java
Log:
Added caching of system name so that calls to getSystemName() don't
travel across the wire when autodetecting the FTPFileEntryParser to
use every time listFiles is called.
dfs 2004/01/06 11:02:03
Modified:net/src/java/org/apache/commons/net/ftp FTPClient.java
Log:
Added caching of the FTPFileEntryParser created in listFiles(String,
String) to avoid creating a new object every tyime the method is
called. This may be regarded as premature
matth 2004/01/06 11:27:18
Modified:sql project.xml
sql/src/java/org/apache/commons/sql/ddl DDLBuilder.java
sql/src/java/org/apache/commons/sql/task DDLTask.java
sql/src/java/org/apache/commons/sql/util DDL.java
sql/xdocs
matth 2004/01/06 11:28:00
Added: sql/src/test/org/apache/commons/sql/task TestDDLTask.java
Log:
I forgot to add the test class.
Revision ChangesPath
1.1
jakarta-commons-sandbox/sql/src/test/org/apache/commons/sql/task/TestDDLTask.java
Index:
On Monday 05 January 2004 10:23 pm, Jeffrey D. Brekke wrote:
On Mon, 05 Jan 2004 21:34:01 -0600, [EMAIL PROTECTED] (Jeffrey D.
Brekke) said:
On Mon, 05 Jan 2004 12:07:28 -0600, steve cohen
[EMAIL PROTECTED] said:
[SNIPPED]
4) rename getFileList(String parserKey, String pathname)
On Monday 05 January 2004 10:31 pm, Jeffrey D. Brekke wrote:
Couldn't we handle this with a FilterIterator or some other adapter on
the iterator from an FTPFileList? I never thought of this when the
version patch was submitted, but it seems like a possible solution.
Better than supporting
I wrote:
Looking at the code, I would have to agree that parseFileList should
be preserved and move into FTPFileEntryParser. That allows us to
rewrite createFileList to call parseFileList instead of
FTPFileList.create, which allows the VMSFTPEntryParser to continue
doing its thing.
Scratch
dfs 2004/01/06 11:53:58
Modified:net/src/java/org/apache/commons/net/ftp
DefaultFTPFileListParser.java
FTPFileEntryParser.java FTPFileListParser.java
Log:
Deprecated FTPFileListParser and copied its parserFileList method to
the
In message [EMAIL PROTECTED], steve cohen writes:
Except for the issue outlined below (re FTPFileListParser deprecation) my
latest commit have implemented everything that Daniel discussed earlier
today:
Great! I added caching of the system name to avoid issuing SYST to the
server for every
On Tuesday 06 January 2004 12:40 pm, Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], steve cohen writes:
There's still one problem with deprecating FTPFileListParser.
The one method of this interface (parseFileList()) is used in the
VMSFTPEntryParser. There is an implementation here
olegk 2004/01/06 12:08:56
Modified:httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java URI.java
httpclient/src/java/org/apache/commons/httpclient/auth
AuthScheme.java BasicScheme.java
olegk 2004/01/06 12:14:21
Added: httpclient/lib commons-codec.jar
Log:
PR #16881 (migrate to commons-codec Base64)
HttpClient made dependent on Commons-codec to perform Base64 and URL
encoding/decoding
Contributed by Oleg Kalnichevski
Reviewed By Michael Becke
olegk 2004/01/06 12:15:09
Modified:httpclient build.properties.sample build.xml
Log:
PR #16881 (migrate to commons-codec Base64)
HttpClient made dependent on Commons-codec to perform Base64 and URL
encoding/decoding
Contributed by Oleg Kalnichevski
Reviewed By Michael
hi niall
patches are much more likely to get promptly applied if they come with
unit tests (hint, hint ;)
1+2 it seemed clear that craig intended no constructors to be available
(and he usually has good reasons for his design decisions) but i think
that allowing WrapDynaClass and WrapDynaBean
olegk 2004/01/06 12:44:05
Modified:httpclient project.xml API_CHANGES_2_1.txt
Log:
PR #16881 (migrate to commons-codec Base64)
HttpClient made dependent on Commons-codec to perform Base64 and URL
encoding/decoding
Contributed by Oleg Kalnichevski
Reviewed By Michael
rdonkin 2004/01/06 12:53:15
Modified:beanutils/src/java/org/apache/commons/beanutils
BeanComparator.java
Log:
Applied improved javadoc patch. Contributed by Tim O'Brien.
Revision ChangesPath
1.9 +47 -17
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18791.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Just a reminder in case it had fallen through the cracks ;-)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Monday, December 29, 2003 14:48
To: Jakarta Commons Developers List
Subject: Re: [collections] Version 3.0 - The final stretch
I have been
I agree with the first, but not the second. 'A utility class' is better than
'An utility class'
Stephen
- Original Message -
From: Michael Heuer [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
scolebourne2004/01/06 13:31:32
Modified:collections/src/java/org/apache/commons/collections
BinaryHeap.java SynchronizedPriorityQueue.java
PriorityQueue.java
Removed: collections/src/java/org/apache/commons/collections
scolebourne2004/01/06 13:43:08
Modified:collections/src/java/org/apache/commons/collections
BufferUnderflowException.java
Log:
Change superclass to NoSuchElementException for better collections integration
Revision ChangesPath
1.9 +10 -6
scolebourne2004/01/06 13:44:43
Modified:collections RELEASE-NOTES.html
Log:
Document the PriorityQueue Buffer changes
Revision ChangesPath
1.6 +6 -1 jakarta-commons/collections/RELEASE-NOTES.html
Index: RELEASE-NOTES.html
scolebourne2004/01/06 14:07:47
Modified:collections/src/java/org/apache/commons/collections
DoubleOrderedMap.java ProxyMap.java
Log:
Update deprecation messages
Revision ChangesPath
1.11 +4 -4
olegk 2004/01/06 14:09:04
Modified:httpclient/src/java/org/apache/commons/httpclient/cookie
Tag: HTTPCLIENT_2_0_BRANCH CookieSpecBase.java
httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH
olegk 2004/01/06 14:10:44
Modified:httpclient/src/java/org/apache/commons/httpclient/cookie
CookieSpecBase.java
httpclient/src/test/org/apache/commons/httpclient
TestCookie.java
Log:
PR #25264 (Cookie rejected)
rdonkin 2004/01/06 14:11:55
jakarta-commons/digester/src/java/org/apache/commons/digester/parser - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rdonkin 2004/01/06 14:13:58
Added: digester/src/java/org/apache/commons/digester/parser
package.html
Log:
Package level documentation for parser guessing schema configuration setting code.
Contributed by Jean-Francois Arcand.
Revision ChangesPath
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25936.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25936.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
In message [EMAIL PROTECTED], steve cohen writes:
After looking at the code, I have a different idea. Reimplementing
createFileList() in terms of parseFileList() would negate the whole reason
for inventing createFileList() in the first place - your suggestion wishing
Agreed. I'm lagging
Hi
I've just started using commons-logging, so I used SimpleLog to get
started. When doing so I found that the output isn't consistent.
With the default settings (showlogname=false, showShortLogname=true) the
output looks like this:
[DEBUG] CodeGenerator - -locale.language=sv
With altered
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25937.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25937.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25936.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25937.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tuesday 06 January 2004 05:53 pm, Daniel F. Savarese wrote:
I think FTPFileEntryParser is the key to customization. All of our
problems would be solved if instead of a static FTPFileList.create
method, there were a per-instance FTPFileList createFileList method
in FTPFileEntryParser.
Robert
Thanks for taking the time to look at this and giving feedback. I take the
hint about the test cases - I'll have to get into how its done in jakarta
some time.
On point 3, I agree about fixing the exception handling in the right place,
rather than in this specific instance. The other
You may want to enter these patches as enhancements in Bugzilla to make
sure that they don't get lost. commons-logging seems to be pretty
stable and hasn't had a release in a while.
Dennis Lundberg wrote:
Hi
When I tried to build commons-logging (pulled from CVS) I needed to find
the right
In message [EMAIL PROTECTED], steve cohen writes:
Almost right, Daniel. I think it filters out dupes when versioning is turned
on.
I thought that's what you said before, but I saw
if (versioning) {
files = super.parseFileList(listingStream);
} else {
in
On Tuesday 06 January 2004 07:08 pm, Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], steve cohen writes:
Almost right, Daniel. I think it filters out dupes when versioning is
turned on.
I thought that's what you said before, but I saw
if (versioning) {
files =
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25940.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25940.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25941.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25941.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
They are now submitted to bugzilla. I wasn't sure what the preferred way
was. Thanks for letting me know.
__matthewHawthorne wrote:
You may want to enter these patches as enhancements in Bugzilla to make
sure that they don't get lost. commons-logging seems to be pretty
stable and hasn't had a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25135.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=18889.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
There seemed to be definite interest in streamable
codecs but the list has gone fairly quiet.
I am interested in participating in work of this
kind but I'm not sure how to proceed.
I don't think this deserves to be a standalone
project as it seems to fit fairly well into the
scope of the current
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21181.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Quoting robert burrell donkin [EMAIL PROTECTED]:
1+2 it seemed clear that craig intended no constructors to be available
(and he usually has good reasons for his design decisions) but i think
that allowing WrapDynaClass and WrapDynaBean to fit better into
DynaBean frameworks seems like a
Weren't ExtendedProperties and BeanMap to be removed?
Or was the decision made to keep them?
Hen
On Tue, 6 Jan 2004, Gary Gregory wrote:
Just a reminder in case it had fallen through the cracks ;-)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Steve/Daniel,
I'm responding to snippets from several messages in this one message,
sorry if it's confusing...
[Iterator idea]
When I suggested the filtering iterator I was thinking of something
really simple, like an additional class or example of how one could
filter off multiple versions
Odi,
Can you give me more details as to why you think this may cause problems with HTTP
pipelining? I am a bit skeptical, as the approach I outlined simply follows the
recommendation of the HTTP spec:
quote
8.2.2 Monitoring Connections for Error Status Messages
An HTTP/1.1 (or later) client
Kalnichevski, Oleg wrote:
Can you give me more details as to why you think this may cause problems with HTTP pipelining?
It won't if done right :-) You just need to make sure that you are
monitoring the response corresponding to the request and not any other
response from previously pipelined
Can you shed any light on the different behavior in Windows vs
HPUX? Not that it will change anything, but I like to learn why these things
behave the way they do to prevent future time wasting activities.
I have had no exposure to HPUX of what so ever, so I may only be guessing here. I
This problem seems like it is the perfect candidate for the
ExpectContinueMethod.setUseExpectHeader() function. Isn't this exactly
the scenario for which this header was intended?
-Eric
Oleg Kalnichevski wrote:
Siddhartha,
I believe the solution to this problem is trivial. All it takes is
that is correct unfortunately I have had the
privilege to work on a webserver which is supposed
to be 1.1 compliant..
I am trying hard to get them to support the 100-expect
continue at the same time I want to see if I can get a
work around.. and hence the mails!!
--- Kalnichevski, Oleg
[EMAIL
Hi Oleg. Welcome back.
I think we also need to add commons-codec to project.xml.
Mike
On Jan 6, 2004, at 3:18 PM, [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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25264.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
67 matches
Mail list logo
