commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From steve cohen <sco...@javactivity.org>
Subject Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Date Thu, 01 Jan 2004 14:16:13 GMT
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.

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?

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 <200312311107.41013.scohen@javactivity.org>, 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 javax.net.SocketFactory
> and javax.net.ServerSocketFactory.  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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message