In message <[EMAIL PROTECTED]>, steve cohen writes:
>Problem is, the current implementations of FTPFileEntryParser, also, for
>reasons of backward compatibility, implement FTPFileListParser. I don't
>remember exactly why I did that but there was a reason. But the problem is
>that deprecating FTPFileListParser will deprecate every parser currently in
>the package.
I don't have a comment on this one yet as I have to look at the code
in more detail. I'm in favor of deprecating the old stuff, but figuring
out the right way to do it isn't immediately obvious. (Actually,
scratch that, now that I've finished writing this email, I have comments
at the end).
>parser and specification of parser either by classname or key ("UNIX", "VMS",
>etc.) will go a long way to making this easier to deal with. The key is to
>now use the new FTPClient.getFileList() methods in place of
>FTPClient.listFiles(). They can use the autodetect feature and never get
>near the question of which parser interface to use. Even if specifying by
>key, all these internals are handled for them. It really should be lots
>better. If anything needs deprecation at this point, I would say it might be
>FTPClient.listFiles().
I disagree slightly (it's actually agreement, but with a naming
difference) and have some suggested code changes (I can make them if
there's agreement). First, the getFileList methods should be
named listFiles() as that's what they're replacing. We can
deprecate the old listFile methods that take FTPFileListParser
arguments and reimplement listFiles() and listFiles(String pathname) in
terms of the new stuff using autodection (removing
getFileList(String parserKey) since the signatures conflict and the
common case will be to use autodetection anyway). Second, we shouldn't
create an FTPFileListParserFactory on every call to getFileList. Instead,
FTPClient should maintain a reference to an FTPFileEntryParserFactory.
This reference should be configurable by the user with a setter
method. That allows API users to change the factory implementation.
Third, we shouldn't set the default factory based on a property.
Once we add the setter method, there is no need for the property.
In general, it's better to let applications handle their configuration
through properties and leave the library free of dependencies on property
values. Which factory to use is an application-level decision (e.g.,
an ant task can define a property that changes the factory for its
purposes), not a library-level decision.
Jeffrey Brekke writes:
>list parsers, and/or implementing the existing list parsers with an
>implementation that uses the entry parsers. That way we are parsing
>with one implementation?
That should be probably be our first step toward deprecation so the
parsers behave consistently. In the 1.2 release we can deprecate the
old listFiles methods presuming we agree to keep the method name for
the files (the class method names currently mirror as closely as possible
the FTP commands they implement). We're stuck by the Commons
versioning/release rules regarding when we can remove the old stuff.
It has to stay in all of the 1.x releases. Otherwise, I'd say that in
1.2 we announce that in 1.3 FTPFileListParserImpl will no longer
implement FTPFileListParser and deprecate the interface in 1.2, removing
it in 1.4 along with the old listFiles() methods. We'll just have to
wait until 2.0. I just tested it, and if we deprecate FTPFileListParser
now, it only affects the javadocs for FTPFileListParser. I think we
can live with any compiler warnings saying that you're using a
deprecated interface as long as we document this. With a J2SE 1.4
compile, you only get warnings for the listFiles methods,
DefaultFTPFileLister (which we also need to deprecate), and
FTPFileListParserImpl, but none of the FTPFileListParserImpl subclasses.
So I propose deprecation in 1.2 and removal in 2.0.
I'd also like to tweak the build files before a 1.2 release because,
given our limited free time, it's excessive to trigger unit tests every
time you build the javadocs since the unit tests don't test anything
in the javadocs. It's just that the unit tests take much so long on
my development box (I'm still using sub-1GHz processors), I need
a way to bypass them when it's not necessary to run them. It's a
tradeoff between productivity and comprehensiveness.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
