Ready for promotion? Was: [io] release plans?

The core EndianUtils is effectively unit tested now. The Stream wrapper methods are not yet, and there aren't numerous different types of unit test etc. Still, as all the Stream methods sit on top of the Endian ones, I think the class is generally protected. This leaves: 1) FilenameUtils. Not go

cvs commit: jakarta-commons/codec LICENSE.txt

ggregory2004/01/01 22:53:49 Modified:codecLICENSE.txt Log: Copyright (c) 2001-2004. Revision ChangesPath 1.6 +1 -1 jakarta-commons/codec/LICENSE.txt Index: LICENSE.txt === RCS file: /h

cvs commit: jakarta-commons/codec LICENSE.txt

ggregory2004/01/01 22:52:40 Modified:codecLICENSE.txt Log: Fix license typo: Products derived from this software may not be called "Apache", *"Apache" nor may "Apache" appear in their name [...] There is a double word in there. This LICENSE FILE is from the mai

cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io EndianUtilsTest.java

bayard 2004/01/01 22:44:54 Modified:io/src/test/org/apache/commons/io EndianUtilsTest.java Log: removed unnecessary line Revision ChangesPath 1.9 +4 -5 jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java Index: EndianUtilsTest.

cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io EndianUtilsTest.java

bayard 2004/01/01 22:44:26 Modified:io/src/test/org/apache/commons/io EndianUtilsTest.java Log: Implemented tests for the unsigned methods and removed the todo comments Revision ChangesPath 1.8 +13 -8 jakarta-commons-sandbox/io/src/test/org/apache/commons/io/E

Re: [collections][lang] 2004

Henri Yandell wrote: On Thu, 1 Jan 2004, Phil Steitz wrote: notices when we change files. One thing that we probably do *not* want to do is to just replace the 2003 references with 2004, since that would make the files from 2003 look like their protection began in 2004. I assume we'd replace -

cvs commit: jakarta-commons-sandbox/io/xdocs tasks.xml

bayard 2004/01/01 22:25:33 Modified:io/xdocs tasks.xml Log: unit test re-enabled Revision ChangesPath 1.13 +0 -1 jakarta-commons-sandbox/io/xdocs/tasks.xml Index: tasks.xml === RCS file: /

cvs commit: jakarta-commons-sandbox/io project.xml

bayard 2004/01/01 22:22:14 Modified:io project.xml Log: removed the IOUtilsTestCase unit test exclusion as it builds for me fine Revision ChangesPath 1.17 +0 -1 jakarta-commons-sandbox/io/project.xml Index: project.xml =

cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io IOUtilsTestCase.java

bayard 2004/01/01 22:18:40 Modified:io/src/test/org/apache/commons/io IOUtilsTestCase.java Log: removed test cases that only test CopyUtils methods, as these methods now have their own tests in the CopyUtilsTest class Revision ChangesPath 1.7 +3 -101 jakarta-c

Re: [collections][lang] 2004

On Thu, 1 Jan 2004, Phil Steitz wrote: > notices when we change files. One thing that we probably do *not* want to > do is to just replace the 2003 references with 2004, since that would make > the files from 2003 look like their protection began in 2004. I assume we'd replace -2003 with -2004

Re: [collections][lang] 2004

On Thu, 1 Jan 2004, Phil Steitz wrote: > Stephen Colebourne wrote: > > I am planning on running licence update scripts across [collections] and > > [lang]. > > > > Any objections to the all file approach? Every file will get the same > > copyright dates. > > The guidlines here http://jakarta.apach

cvs commit: jakarta-commons/net/src/test/org/apache/commons/net/telnet EchoOptionHandlerTest.java InvalidTelnetOptionExceptionTest.java SimpleOptionHandlerTest.java SuppressGAOptionHandlerTest.java TelnetClientFunctionalTest.java TelnetClientTest.java TelnetOptionHandlerTestAbstract.java TelnetOptionTest.java TelnetTestResponder.java TelnetTestSimpleServer.java TerminalTypeOptionHandlerTest.java

scohen 2004/01/01 19:39:07 Modified:net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2 FTPClient2.java FTPFileEntryParser.java FTPFileIterator.java FTPFileList.java net/proposal/ftp2/src/java/org/apache/commons/net/f

Re: [collections][lang] 2004

Aw, phooey. I just changed the dates on all the commons-net classes. Wish I had seen these instructions beforehand. On the other hand, with one exception they all contained "2001", which, as far as I can recall, was before these classes came under the Jakarta umbrella. If memory serves, they

Re: [collections][lang] 2004

Stephen Colebourne wrote: I am planning on running licence update scripts across [collections] and [lang]. Any objections to the all file approach? Every file will get the same copyright dates. The guidlines here http://jakarta.apache.org/site/source.html say " Committers should update the copyri

Re: [collections] BinaryHeap and PriorityQueue

Stephen Colebourne wrote: From: "Phil Steitz" <[EMAIL PROTECTED]> Stephen Colebourne wrote: > Given a choice I would deprecate PQ altogether. That would make things simpler. If no one else comments, I'll do this. I am +1 on renaming to PriorityBuffer. Done I was also looking at the heap impl an

[collections][lang] 2004

I am planning on running licence update scripts across [collections] and [lang]. Any objections to the all file approach? Every file will get the same copyright dates. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For add

cvs commit: jakarta-commons/collections LICENSE.txt

scolebourne2004/01/01 18:19:25 Modified:collections LICENSE.txt Log: New license for 2004 Revision ChangesPath 1.4 +2 -6 jakarta-commons/collections/LICENSE.txt Index: LICENSE.txt === RCS

DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-commons/collections project.xml

psteitz 2004/01/01 16:05:56 Modified:collections project.xml Log: Added Steve Phelps as contributor. Restored alpha sort order. Revision ChangesPath 1.22 +6 -3 jakarta-commons/collections/project.xml Index: project.xml ===

cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/buffer TestBinaryBuffer.java

psteitz 2004/01/01 15:56:51 Modified:collections/src/java/org/apache/commons/collections BinaryHeap.java collections/src/java/org/apache/commons/collections/buffer BinaryBuffer.java collections/src/test/org/apa

Re: [collections] BinaryHeap and PriorityQueue

Stephen Colebourne wrote: I am happy for Buffer to exist in [collections] (although I wish the methods were peek and pop) Yeah. Like a queue ;-). > Given a choice I would deprecate PQ altogether. That would make things simpler. Your change will need to be applied to both BinaryBuffer and Bin

Re: [net] Tag NET_1_1_1 created

Should we roll out a release of this version? -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED]

Re: [collections] BinaryHeap and PriorityQueue

> > We could go further and actually deprecated PQ. But I'm a little wary of > > that. > > We should decide whether or not Queue implementations belong in > [collections]. I am +0 on this (the "+" is because BinaryHeap/Buffer > exists). If no, we should deprecate. See below. > > > > (And both Bin

[net] Tag NET_1_1_1 created

This is the version with all JDK 1.1 incompatible code "dumbed down" to the 1.1.8 level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/net/src/java/examples ExtendedNNTPOps.java TelnetClientExample.java

scohen 2004/01/01 13:31:21 Modified:net/src/java/examples ExtendedNNTPOps.java TelnetClientExample.java Log: more copyright date changes Revision ChangesPath 1.4 +1 -1 jakarta-commons/net/src/java/examples/ExtendedNNTPOps.java Inde

cvs commit: jakarta-commons/net/src/test/org/apache/commons/net/ftp/parser EnterpriseUnixFTPEntryParserTest.java FTPParseTestFramework.java NTFTPEntryParserTest.java OS2FTPEntryParserTest.java UnixFTPEntryParserTest.java VMSFTPEntryParserTest.java

scohen 2004/01/01 13:04:22 Modified:net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2 FTPClient2.java FTPFileEntryParser.java FTPFileIterator.java FTPFileList.java net/proposal/ftp2/src/java/org/apache/commons/net/f

Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?

Yes, in order to verify that the code doesn't use any 1.2+ code I found that you have to also use bootclasspath={path to jdk1.1.8 classes.zip} There were a couple of other instances: use of ArrayLists in VMSFTPEntryParser and in ExtendedNNTPOps.java in the examples section. I cleaned all of thes

cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser VMSFTPEntryParser.java

scohen 2004/01/01 12:49:49 Modified:net/src/java/examples ExtendedNNTPOps.java net/src/java/org/apache/commons/net/ftp/parser VMSFTPEntryParser.java Log: refactor back to JDK 1.1 compatibility. HashMap -> Hashtable ArrayList -> [] or use St

Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?

I believe it just produces 1.1 compatible class files. Maven just passes the setting to the ant task, which passes it to javac. Since the HashMap class is is not present under 1.1 I guess we'd just get a ClassNotFoundException. I believe that should be all we need, we shouldn't need to *compile

Re: [collections] BinaryHeap and PriorityQueue

Sorry to respond first to the commit message (must be all the "oversight talk" ;) See interspersed. Stephen Colebourne wrote: I have made the following changes: - PriorityQueue now disapproved (not deprecated, but the language indicates it is) - BinaryHeap in main package is not deprecated, as i

Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java

See other thread;-) - Original Message - From: "Phil Steitz" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, January 01, 2004 7:11 PM Subject: Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/buffer BoundedFifoBuffer.java UnboundedFifoBuffer.java

scolebourne2004/01/01 11:24:46 Modified:collections/src/java/org/apache/commons/collections/buffer BoundedFifoBuffer.java UnboundedFifoBuffer.java Log: Apply collection coding standards Revision ChangesPath 1.4 +46 -42 jakarta-commons/col

Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java

[EMAIL PROTECTED] wrote: scolebourne2004/01/01 11:00:20 Modified:collections/src/java/org/apache/commons/collections BinaryHeap.java Log: Undeprecate, as is only implementation of PriorityQueue What is the plan here? We don't want to maintain two implement

Re: [collections] BinaryHeap and PriorityQueue

I have made the following changes: - PriorityQueue now disapproved (not deprecated, but the language indicates it is) - BinaryHeap in main package is not deprecated, as it is the only implementation of PQ - BinaryHeap in buffer subpackage renamed to BinaryBuffer. No longer implements PQ - PQ decora

cvs commit: jakarta-commons/collections RELEASE-NOTES.html

scolebourne2004/01/01 11:05:05 Modified:collections RELEASE-NOTES.html Log: Undeprecate BinaryHeap, as is only implementation of PriorityQueue Revision ChangesPath 1.4 +1 -1 jakarta-commons/collections/RELEASE-NOTES.html Index: RELEASE-NOTES.html ===

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/buffer BinaryBuffer.java package.html BinaryHeap.java

scolebourne2004/01/01 11:01:34 Modified:collections/src/test/org/apache/commons/collections/buffer TestAll.java collections/src/java/org/apache/commons/collections/buffer package.html Added: collections/src/test/org/a

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java

scolebourne2004/01/01 11:00:20 Modified:collections/src/java/org/apache/commons/collections BinaryHeap.java Log: Undeprecate, as is only implementation of PriorityQueue Revision ChangesPath 1.16 +19 -15 jakarta-commons/collections/src/java

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections PriorityQueue.java

scolebourne2004/01/01 10:58:55 Modified:collections/src/java/org/apache/commons/collections PriorityQueue.java Log: PriorityQueue is replaced by Buffer Revision ChangesPath 1.9 +7 -8 jakarta-commons/collections/src/java/org/apache/commo

cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections PriorityQueueUtils.java SynchronizedPriorityQueue.java

scolebourne2004/01/01 10:57:37 Modified:collections/src/java/org/apache/commons/collections PriorityQueueUtils.java SynchronizedPriorityQueue.java Removed: collections/src/java/org/apache/commons/collections/buffer

DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-commons/net project.xml

scohen 2004/01/01 09:33:03 Modified:net project.xml Log: change organization under Steve Cohen's id. Revision ChangesPath 1.36 +1 -1 jakarta-commons/net/project.xml Index: project.xml =

Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?

On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote: > Maven uses the following property: maven.compiler.target which > defaults to 1.1 so what I last released generated 1.1 compatible class > files. > > http://maven.apache.org/reference/plugins/java/properties.html > > Example: > maven

Re: Best place for CPIO io streams

Thanks for your help Phil and Noel. I will open a ticket as soon as I have the CPIO input/output stream ready and I'm satisfied with the functionality. Happy new Year. Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additio

Re: [net] Branching

Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_5.html#SEC56 Given that, as per Steve's message, we can make

Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?

> On Thu, 01 Jan 2004 08:16:13 -0600, steve cohen <[EMAIL PROTECTED]> said: > Seems to me the HashMap ---> Hashtable change could be made against > HEAD. It's only NECESSARY for 1.1 compatibility but it poses no > great problem for a 1.2 compatible version; it isn't as if this > would impact

Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?

Seems to me the HashMap ---> Hashtable change could be made against HEAD. It's only NECESSARY for 1.1 compatibility but it poses no great problem for a 1.2 compatible version; it isn't as if this would impact some functionality deep in the core of the product. So after this is done, a NET_1_1

Re: [Latka]Following references

Hi, I provided this patch a couple of weeks ago and got no reaction. So I just want to ask whether there is anybody who has an eye on patches and further development of this component. BTW: Has there ever been a release of Latka? Oli Oliver Heger wrote: Hi, as I have promised I created a pa