commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbre...@wi.rr.com (Jeffrey D. Brekke)
Subject Re: [net] Solved VMS duplicates problem and simplified system
Date Mon, 12 Jan 2004 13:31:28 GMT

I'm still trying to keep up with the code changes and discussion, but
currently I'm getting a compile failure:

----

java:compile:
    [echo] Compiling to /usr/local/jbrekke/sandbox/other/commons-net/target/classes
    [javac] Compiling 70 source files to /usr/local/jbrekke/sandbox/other/commons-net/target/classes
/usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/net/ftp/FTPFileListParserImpl.java:152:
cannot resolve symbol
symbol  : class DefaultFTPFileList 
location: class org.apache.commons.net.ftp.FTPFileListParserImpl
        DefaultFTPFileList list = new DefaultFTPFileList(this);
        ^
/usr/local/jbrekke/sandbox/other/commons-net/src/java/org/apache/commons/net/ftp/FTPFileListParserImpl.java:152:
cannot resolve symbol
symbol  : class DefaultFTPFileList 
location: class org.apache.commons.net.ftp.FTPFileListParserImpl
        DefaultFTPFileList list = new DefaultFTPFileList(this);
                                      ^
2 errors

BUILD FAILED
File...... file:/home/jbrekke/.maven/plugins/maven-java-plugin-1.3/
Element... ant:javac
Line...... 34
Column.... 48
Compile failed; see the compiler error output for details.
Total time: 13 seconds
Finished at: Mon Jan 12 07:47:30 CST 2004

----

Are all your changes committed?

>>>>> On Sat, 10 Jan 2004 10:20:42 -0600, steve cohen <scohen@javactivity.org>
said:

> I have made a rather large checkin to fully solve the VMS problem.
> (Actually, there is one more detail, but it is minor, see below).

> These changes were as follows:

> 1. Subclass VMSFTPEntryParser with VMSVersioningFTPEntryParser.
> This subclass handles the duplicate removal at what I believe is the
> right time: After the initial list is read in, but within the
> process of FTPFileList creation, that is before FTPFileList.create()
> returns.  No client of the list sees the removed dupes.

> 2. In order to implement one, a removeDuplicates() method was added
> to FTPFileEntryParser.  This is a no-op in the normal case but
> implemented in VMSVersioningFTPEntryParser.

> 3. You'll note I said FTPFileList.create() in #1.  I reverted to
> this and removed FTPFileEntryParser.createFTPFileList() that Daniel
> had added.  He was uncomfortable with the name of this method, and
> it was no longer necessary with the above changes.  I also removed
> DefaultFTPFileList and DefaultFTPFileIterator.  Since these are
> large changes and potentially step on Daniel's toes, I created a tag
> NET_1_2_0_TEMP so we can revert if anyone strenuously objects.

> 4.  I renamed FTPFileListParserImpl to FTPFileEntryParserImpl to
> reduce the confusion level since FTPFileListParser is now deprecated
> and going away in 2.0.  For the time being, though, for backward
> compatibility it still implements FTPFileListParser.

> This has been a painful exercise, so I want to give my thinking.
> Probably FTPFileList and FTPFileListIterator are misnamed.
> FTPFileList IS-NOT-A List of FTPFiles.  It HAS a Vector of raw input
> lines from the listing.  FTPFileListIterator IS-NOT-A simple
> iterator over FTPFileList.  It DOES iterate over this Vector and
> DOES return FTPFile objects, so it is more than a simple iterator,
> it is an iterator on steroids.

> Remember that there are two scenarios supported here: a) read the
> whole list at once as in FTPClient.listFiles() and b) read the list
> in but defer creation of more expensive FTPFile objects until
> needed.  This scenario was broken in the VMS case.


> The nice thing about this fix is that both scenarios are supported,
> and complications are much reduced.

> The one thing left to do is decide which VMS scenario, versioning or
> non-versioning is the default, i.e. the one to be supported by
> autodetection.  I asked for someone to chime in on this last week
> and no one has.  I still don't know.

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

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com


---------------------------------------------------------------------
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