<[EMAIL PROTECTED]> writes: > I've begun to migrate code out of Utils and into some of the new packages. > Currently I've created a lang package and moved the relevant code into the > codec package. I've also finished the migration of code to IO, removing > the old classes and also sending HexDump on over.
Good on you. > One issue of this is that at the moment, XmlUtils and GenerateUniqueId > both fail to compile due to dependency on String[Util]s. As does > RequestUtils. I just fixed GenerateUniqueId. > Collections package. > Move CollectionsUtils to Collections as ?, merge? > Move MapUtils over to Collections as Maps. > SequencedHashtable and BufferCache to be removed. > EnumerationIterator to be removed. > Transfer StringStack to Collections. > > Util retains [and stays in sandbox currently] > org.apache.commons.util.GenerateUniqueId > org.apache.commons.util.Xml > org.apache.commons.util.BitField > org.apache.commons.util.compare.* > org.apache.commons.util.lru.* What is the reasoning for not moving lru.* into Collections and/or merging with LRUMap? I nuked the other duplicate Collections-type code from Util (BufferCache and SequencedHashtable and their tests). Since Util has never had final release, this should be fine. EnumerationIterator is already in Collections (so should go ASAP), but Util's CollectionUtils still depends on it. > I apologise for the 3 currently uncompiling classes, and if I misunderstood > anyones opinions in the targets for migration. I think what I've done matches > everyone's shared views. What you did looked like the consensus (and is fine with) me. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
