[ 
https://issues.apache.org/jira/browse/PIVOT-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668012#comment-13668012
 ] 

Roger Whitcomb commented on PIVOT-864:
--------------------------------------

Hi Sandro,
   I understand your concern.  I don't think all these are absolutely necessary 
for building, nor deployment.  You get runtime logging notices, but not errors, 
if not all are included.  But, the Commons VFS team is not finished with the 
2.0 release, which is why it is still SNAPSHOT.  I will update / delete .jar 
files as I figure out which ones are absolutely necessary, and update to the 
real release VFS .jar once they release.  But, I figure we're still some months 
away from releasing 2.1 so there should be some time to figure this all out.  I 
think the only one that is absolutely necessary to build and browse local 
filesystems is the Apache Commons VFS .jar file, so if that's all we include in 
our release, I think it will be enough to build with, and there shouldn't be a 
problem with that.  I really wanted to get something out there so you (and 
others) could take a look at what I'm doing, and make these kinds of 
observations/concerns.
   And I did some tests and you don't need any of them (not even Commons VFS) 
to run with IF you don't use the new classes .... (same as with the SVG 
support).
   But, I will definitely try to reduce the number of .jars needed to build 
with and update the NOTICE/BUILD files about how to deal with them.  I'm sure 
the Commons folk will also update their build/deployment instructions once they 
release the real 2.0 version, and then we can refer to those as well.  Right 
now I had to dig around in the mvn repositories to even figure out this set of 
.jar files :(  But, this set was necessary to not have any logging messages 
come out when I initialized the default VFS file system manager, according to 
their list of "supported" plugins.  But, of course, anyone can initialize their 
own version of the file system manager and add/remove whatever plugins they 
want....  So, possibly I could do a different initialization by default, too, 
that wouldn't have so many schemes supported.
   Still a work-in-progress, so ....  Thanks for the comments :)
                
> Add a pluggable file system architecture to FileBrowser so remote browsing 
> can be done
> --------------------------------------------------------------------------------------
>
>                 Key: PIVOT-864
>                 URL: https://issues.apache.org/jira/browse/PIVOT-864
>             Project: Pivot
>          Issue Type: New Feature
>          Components: wtk
>    Affects Versions: 2.0.2
>         Environment: Windows, Linux, OSX
>            Reporter: Roger Whitcomb
>            Assignee: Roger Whitcomb
>              Labels: filebrowser
>             Fix For: 2.1
>
>         Attachments: vfs.patch
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Our application requires the ability to be able to browse (for instance) a 
> Linux machine from the Windows desktop.  For this I would like to add 
> (somehow) a pluggable file system architecture so that I could (for instance) 
> implement an FTP protocol underneath the FileBrowser so that I can browse 
> through directories and files on something other than the local machine.  We 
> would also need to be able to type in a host name or TCP/IP address to start 
> browsing the remote machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to