commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brekke, Jeff" <Jeff.Bre...@qg.com>
Subject RE: [PATCH] - New FTP File Listing Mechanism
Date Mon, 29 Apr 2002 12:32:33 GMT
How about some unit tests exercising the parsing and interaction.
A document for usage would also be nice.  We can add it to the site docs
maybe start some small how-to's or tutorials or something centered around
the major portions of the api ( ftp, telnet, etc. )

=================================================================
Jeffrey D. Brekke                                   Quad/Graphics
Jeff.Brekke@qg.com                              http://www.qg.com


> -----Original Message-----
> From: Steve Cohen [mailto:stevecoh1@attbi.com]
> Sent: Sunday, April 28, 2002 11:02 PM
> To: Jakarta Commons Developers List
> Subject: Re: [PATCH] - New FTP File Listing Mechanism
> 
> 
> Jeff
> That's cool.  I have no problem with such stylistic changes.
> 
> My idea, because I can't think of a better one, is eventually 
> to replace 
> FTPClient with FTPClient2.  (If you can think of better class 
> and package 
> names, I wouldn't quarrel with you!)  I had an original 
> implementation that 
> had all the FTPClient2 listFiles methods in listFiles.  I 
> hadn't seen the 
> guideline that files be kept to 2000 lines or less (which 
> FTPClient is even 
> now in violation of) but with all the new methods in 
> FTPClient, it just felt 
> too long and complicated to me.  (Imagine FTPClient and 
> FTPClient2 all in one 
> class!) And yet I knew I couldn't break backward compatibility, so my 
> approach was the lesser of evils as I saw it.
> 
> After a period of experimentation, if the community sense is 
> to deprecate the 
> older methods, then that can and should be done.  
> 
> Do you think a document illustrating the usage of FTPClient2 
> would be helpful?
> 
> Steve
> 
> 
> 
> On Sunday 28 April 2002 10:21 pm, you wrote:
> > I'll just apply what I have an we can clean up after.  I 
> did change the
> > format of the code in the patch to match more closely the 
> coding style
> > posted on the site.  No functional changes, just spacing, 
> author/version
> > fixes, and import statement cleansing.
> >
> > Is the idea to move forward and replace FTPClient with 
> FTPClient2 or add in
> > the functionality some other way?  I suppose a nice way to 
> deprecate the
> > older listing methods and still have the new versions 
> should be the next
> > topic of discussion?  Although we could just replace the 
> listing stuff for
> > the first release of this, I think maintaining the older 
> interface would be
> > the best for users.  Then users of the orig netcomponents 
> code would really
> > just need to change package names.
> >
> > =================================================================
> > Jeffrey D. Brekke                                   Quad/Graphics
> > Jeff.Brekke@qg.com                              http://www.qg.com
> >
> > > -----Original Message-----
> > > From: Steve Cohen [mailto:stevecoh1@attbi.com]
> > > Sent: Sunday, April 28, 2002 9:40 AM
> > > To: Brekke, Jeff
> > > Subject: Re: [PATCH] - New FTP File Listing Mechanism
> > >
> > >
> > > Say Jeff:
> > > I was looking back over my code and I see one thing that I
> > > meant to clean up
> > > and forgot about:
> > >
> > > FTPFileList.create() (FTPFileList.java, line 85) eats the
> > > IOException instead
> > > of throwing it, as it should (and as the analogous
> > > functionality in Daniel's
> > > code does).  Worse, it System.out.println's the error.
> > >
> > > Would you rather I clean this now, or get it in as soon 
> as the commit
> > > happens?  I'd rather not send a whole new patch that's 99%
> > > the same as the
> > > other, but I will leave up to you the best way to handle it.
> > >
> > > Steve
> > >
> > > On Sunday 28 April 2002 07:33 am, Brekke, Jeff wrote:
> > > > Thanks Steve.  I've integrated your patch and 
> looking at it now.
> > > > I've recently placed the projects generate documentation here:
> > > >
> > > > http://jakarta.apache.org/commons/sandbox/net
> > > >
> > > > It include javadocs, metrics report, checkstyle report,
> > >
> > > etc. that maven
> > >
> > > > generates.
> > > >
> > > > 
> =================================================================
> > > > Jeffrey D. Brekke                                   
> Quad/Graphics
> > > > Jeff.Brekke@qg.com                              
> http://www.qg.com
> > > >
> > > > > -----Original Message-----
> > > > > From: Steve Cohen [mailto:stevecoh1@attbi.com]
> > > > > Sent: Saturday, April 27, 2002 1:16 PM
> > > > > To: commons-dev@jakarta.apache.org
> > > > > Subject: [PATCH] - New FTP File Listing Mechanism
> > > > >
> > > > >
> > > > > The attached patch implements an alternative file listing
> > >
> > > mechanism.
> > >
> > > > > While designed to replace and enhance the original mechanism,
> > > > > complete
> > > > > backward compatibility is preserved.
> > > > >
> > > > > This patch was originally submitted in a slightly different
> > > > > form before the
> > > > > NetComponents project was moved to the Jakarta Sandbox in
> > > > > April 2002.  I am
> > > > > also attaching the original comments that were 
> submitted with that
> > > > > submission.  They are all still valid.  The only differences
> > > > > between the
> > > > > earlier patch and this one are these
> > > > > 1) my email address is different
> > > > > 2) the package names were changed to conform with the new
> > > > > commons location
> > > > > 3) licenses were changed to Apache
> > > > > 4) the File Parsers and their associated test classes were
> > > > > moved to a new
> > > > > subpackage:
> > > > > 	org.apache.commons.net.ftp.ftp2.parser
> > > > > for greater clarity.
> > > > > 5) project.properties has been changed so that new
> > > > > Maven-based build (a
> > > > > really nice system, by the way, which I hadn't known about)
> > > > > knows where to
> > > > > find the test classes.
> > > > >
> > > > > I would have liked to submit this patch in smaller pieces but
> > > > > it is really
> > > > > impossible to do so and still have a functioning package.
> > > > > Breaking the
> > > > > parsers into a subpackage perhaps makes clearer that the
> > > > > changes are really
> > > > > not massive.
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 

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


Mime
View raw message