In message <[EMAIL PROTECTED]>, steve cohen writes: >Is there a recommended way to go about this? It was doubtful to me that >anyone had ever used these packages, but I now see that I was wrong. Someone >went and implemented an AIXFTPEntryParser in the ftp2.parser package (and not >on the main stem). > >So I would be in favor of moving this class onto the main stem and deprecating >everything in ftp2.
Definitely +1 on this, but it's already been done. You must have an old checkout that you're doing cvs updates on. It's a good thing too since you wouldn't have caught the AIXFTPEntryParser sitting there. We ought to look at the log entries and see if it was subsumed by the functionality in one of the other parsers. In any case, everything in ftp2/ and ftp/parser/ is in the Attic/ in the CVS repository, so when you do a fresh checkout, the directories will be empty. My .cvsrc adds -P to checkout and update (doesn't checkout empty directories), so I didn't know what you were talking about at first. Okay, scratch what I just said. I see, you're talking about what's in the proposal directory. Yeah, definitely get rid of proposal/ftp2. The way to do it is to delete the files and do cvs removes. After looking at the log entry for AIXFTPEntryParser, I see I added it: >revision 1.1 >date: 2003/01/28 18:53:04; author: dfs; state: Exp; >Added AIX listing parser from Brett Smith <brett at bml.uk.com>. That was in the 1.0 release, before the proposal was moved into the ftp package. The files in src/java/org/apache/commons/net/ftp/parser were added later and first appear in the 1.1 release candidate. So AIXFTPEntryParser didn't get copied from the proposal directory for some reason. I'm not in the best position to do the detective work on this right now, but can look at it tomorrow night if you don't have time to figure out if AIXFTPEntryParser functionality is already provided by another entry parser or if we just missed it when migrating the entry parsers. I suppose the proposal directory is another possibility I hadn't considered for doing work on a java.nio version of the code. In these [net] threads, I think we've pretty much made the case for switching to Subversion sooner rather than later. Subversion is close to a 1.0 release and I believe they've stopped modifying the database schema, so the question will become whether all of Jakarta Commons should move to Subversion at once or piecemeal and when. But that's a subject for a different thread. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
