Comments below. --- [EMAIL PROTECTED] wrote: > > src/java/org/apache/commons/util/BitField.java > > I missed this one :) It seems un-IO.
Yeah, at second glance, maybe it could go in commons/lang? It seems more like Byte, Integer, etc. than IO stuff. It's unfortunate that Sun packaged BitSet in java.util.*. BitSet and BitField are kinda siblings. > > > src/java/org/apache/commons/util/BufferCache.java > > Again. un-IO? Yeah, I was mislead by its class name. How is this used? Perhaps it needs to be renamed and put in Collections. > > src/java/org/apache/commons/util/http/BrowserDetector.java > > src/java/org/apache/commons/util/http/HttpUtils.java > > src/java/org/apache/commons/util/http/RequestUtils.java > > There's been suggestion for a 'servlet' package. These might go in > there, > though IO seems an option too. Sounds good. > > src/java/org/apache/commons/util/LockableFileWriter.java > > src/java/org/apache/commons/util/StreamUtils.java > > src/java/org/apache/commons/util/GenerateUniqueId.java > > This has no IO-ness to it at all? Are you saying that these are not IO? GenerateUniqueId could go in servlet (if that's its main usage). The others seem undeniably IO. > > src/test/org/apache/commons/util/BitFieldTest.java > > src/test/org/apache/commons/util/BufferCacheTest.java > > src/test/org/apache/commons/util/HexDumpTest.java > > src/test/org/apache/commons/util/SequencedHashtableTest.java > > I assume not to the last one. And BufferCache. And bitfield :) Oops, my mistake. > > [COLLECTIONS] > The only issue with the compare/ library is dependency. It depends on > Lang > so Collections might not want it until Lang is there. Hmm... Good point. That's difficult to resolve. Perhaps a collections extension package of comparators? It seems like the basic data stores in collections should have no outside dependencies. However, extensions with dependencies might be good. > > src/java/org/apache/commons/util/XmlUtils.java - [XERCES? JDOM?] > > Getting it lost in those projects seems wrong. I think the goal of an > xml > subproject would be to provide somethign more than indexOf, but less > than > a parser. I'm happy to do a proposal for this subproject too, or for > it to > go into Lang or IO or stay in the sandbox. Yeah, Xerces would be overkill. XMLUtils is much more centered around String snippets within a larger XML-ish context. It may be useful to have a full package of such tools. However, take a look at http://www.jdom.org/docs/apidocs/ - org.jdom.Element - org.jdom.output.XMLOutputter - org.jdom.intput.* You may be surprised at how small and useful the package is. You can do a lot without creating an entire DOM, and it handles all the escaping issues nicely. Perhaps String-centered pieces could be incorporated into org.jdom.input.* for easy pseudo-parsing. JDom is currently Apache-like licensed. It has been accepted as JSR-102, so who knows what will happen once Sun gets a hold of it! __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
