I agree that we should avoid using commons-colelctions. I will make it an inner class of FastDateFormat instead. I'll also hold off on submitting it until I have a complete set of test cases (or at least what I perceive to be complete.)
My paying job is keeping me busy but I hope to have all of this done by end of next week. My hope is that once this is done we can get back to discussing where to go from there and make some decisions on what should go in to the time subpackage.
Hopefully those that expressed interest earleir are still on board with this. I think it will be a nice addition to commons-lang if we keep it tight and limit features to those that solve very general problems.
- sean
From: "Sean Schofield" <[EMAIL PROTECTED]>
Here's where I am at with FastDateFormat. I changed the package nameThis dependency should be avoided, so yes an inner class is appropriate.
(to org.apache.commons.lang.time.) I also pulled down the source code
for Pair that it required. I noticed that Pair seemed like the
DefaultMapEntry in commons-collections (am I wrong?) Is commons-lang
allowed to have dependencies with commons-collections or should we try
to avaoid that? (My guess is you will say avoid.)
Finally, I wrote a few unit tests for FastDateFormat. Once we resolveI would prefer unit tests to be there before adding to the CVS, but if it
the Pair issue I'd like to submit FastDateFormat and FastDateFormatTests
to be added to CVS. Do we need all of the unit tests to be complete
before adding? There are a lot to write and I know Eric, and others are
also volunteering to help here.
helps make the work visible then sometimes it can be committed without.
Stephen
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
