Community
Participate
Working Groups
One of the biggest benefits of Jakarta Commons/Net is the framework for custom FTP Listing parsers. We should not hide this inside our implementation, but provide API (or an extension point?) to allow clients register their own listing parsers. Use cases for this include VxWorks, which should be moved out of the core implemenation and use the provided API instead (bug 176215); UNIX/Windows mismatches (bug 169610); and servers using a numerical date format (http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg00905.html) The way how the current vxworks contribution is done (overriding the parser) could serve as a helper when defining the API.
From Javier: It would be easiest to extend the parsers using an extension point and a property to select the parser to be used (similar as the FTP active/passive mode). This solution would also fix bug 169610 as it could be possible forcing a specific parser rather than leaving the FTP engine to guess it. With this solution, I think the bug could be fixed for the next milestone
Created attachment 64021 [details] Patch providing extension point for parsers and implementations for improved VMS and WinNT parsing
Martin, Could you check if after applying the patch you are able to add the VxWorks FTP parser extension ? It may give an idea on how easy/diificult is providing new parsers using the extension point.
Custom listing parsers can be added though the extension point org.eclipse.rse.subsystems.files.ftp.ftpFileEntryParser
[target cleanup] 2.0 M7 was the original target milestone for this bug
Comment on attachment 64021 [details] Patch providing extension point for parsers and implementations for improved VMS and WinNT parsing iplog- since Javier became committer in 2006 already: http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg00375.html
