commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Jeffrey D. Brekke)
Subject Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Date Thu, 01 Jan 2004 15:06:35 GMT
>>>>> On Thu, 01 Jan 2004 08:16:13 -0600, steve cohen <>

> 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_1 tag could be created and that could
> be the final of this branch.

This sounds like a good idea.  Make the 1.1 compatibility on HEAD,
tag, and if need be branch from that tag point for 1.1 fixes.

> On the other hand, if there are other 1.1 incompatibilities we may
> want to fix those too, and then this might get a little
> problematical.  Hey, Jeffrey, do you know if there's an easy way to
> make Maven do a JDK 1.1 compile?  Or would it be easier to just
> tinker with the generated ant script?

Maven uses the following property: which
defaults to 1.1 so what I last released generated 1.1 compatible class

maven clean jar

> On the subject of the pluggable parser factory, I'm not sure I see
> the need, but it's easy enough to do it that way, so I will make the
> change.  Am I correct in assuming that in your plan there would be a
> default implementation, with other factories being selectable
> instead on the basis of a property?

> On Wednesday 31 December 2003 10:42 pm, Daniel F. Savarese wrote:
>> In message <>, steve cohen
>> writes: >I am not completely CVS-literate and setting up the
>> branches is beyond my >current level of experience but probably
>> would be good experience for me.
>> In my response to Jeffrey's email, I asked about whether we wanted
>> to replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch
>> tag or leave the existing tag alone and attach a special branch tag
>> with a different name to the NET_1_1_0 files.  After we resolve
>> that, if you want to do it, go ahead.  I don't know if you can use
>> the -F and -b options together with cvs tag, which is why I
>> suggested the roundabout way of renaming the tag and creating a new
>> one with the old name using -b.  Subversion makes this easier.
>> >without requiring it to have far more knowledge of commons-net
>> internals > than I think is healthy.  So I am developing an
>> FTPFileEntryParserFactory > and some convenience methods in
>> FTPClient to enable Ant to be recoded > decently.
>> I followed the emails.  Sounds great.  I forgot to offer a comment.
>> I was going to suggest making FTPFileEntryParserFactory either a
>> class or an interface that has to be instantiated rather than a
>> singleton.  I think you were intending to make
>> createFileEntryParser a static method.  I suggest the use of an
>> interface and a default factory class for the same reason we had to
>> write SocketFactory and much later, in J2SE 1.4, Sun added its own
>> and  It
>> allows generic code to be written that accepts pluggable parser
>> factories should a user decide to implement his own factory.  I'm
>> thinking about the automatic detection code you alluded to, which
>> could then be configurable/extensible through the insertion of
>> parser factories.
>> >I can also make the HashMap-->Hashtable change for the 1.1.1
>> branch.  The > JDK 1.1 incompatibility was DISCOVERED through
>> failure of the unit test > but the offending code is in the class
>> being tested, not the test itself.  > I have
>> Sure thing.  Let's decide how to tag that branch.
>> >And it sounds like you have an itch for doing the nio stuff.
>> It's been nagging me for a while, but I'm actually writing
>> networking code these days based on java.nio, so I figure I should
>> kill two birds with one stone and start rolling it into Commons Net
>> as a proposal instead of keeping it in my private library.  It's so
>> much easier to dedicate volunteer committer hours when you're
>> working on/using the stuff anyway.
>> daniel
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Jeffrey D. Brekke                         
Wisconsin,  USA                           

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message