Community
Participate
Working Groups
The Platform/Team Target Management component including its FTP and WebDAV connectors is being discontinued as of Eclipse 3.3: http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg01040.html Target Management / RSE is the logical successor of this functionality. We should therefore move the WebDAV code to the TM Repository and write an adapter layer that makes WebDAV available as an RSE subsystem / service. The Service layer should be thin enough to allow re-using WebDAV without much overhead, and make it available as an EFS contributor at the same time. This will likely happen after TM 2.0; community help would be appreciated.
There is an Google Summer of Code project for providing an EFS implementation of WebDAV (see http://wiki.eclipse.org/index.php/Google_Summer_of_Code_2007). Perhaps you want to touch base with them to see if they would be willing to provide RSE integration as well.
CC'ing Reid as well. He is the student working on this project.
Michael - thanks for setting up this contact, this looks like a great opportunity! Gunnar, Reid - we are very interested in collaborating with you on a WebDAV EFS provider. Here are some random thoughts: * Having WebDAV as a service below RSE gives you the advantage that you can leverage the RSE framework for handling credentials and connection properties, it gives you a ready-made EFS provider with remote file browse dialogs and persistent connection management. * Disadvantage of RSE right now is that it has no clean UI/Non-UI separation yet, this is one of the reasons why a remote project (with the .project file on EFS) is not re-opened on startup (See bug 181460); you could avoid this issue with a minimal-dependency EFS provider without RSE, that does not depend on core.resources as we (unfortunately) do. If you want to browse our code, see the CVS setup page at http://www.eclipse.org/dsdp/tm/development/cvs_setup.php Best import the "rse-anonymous.psf" team project set into a workspace. Implementing the RSE IFileService API is pretty simple, you could have a look at our plugins org.eclipse.rse.subsystems.files.ftp org.eclipse.rse.services.files.ftp org.eclipse.rse.services.ssh for reference. The FTP case also shows how a 3rd party Apache library (in our case Jakarta Commons Net) is set up and re-used from Orbit. If you want to have a look at our EFS provider, it is in org.eclipse.rse.eclipse.filesystem If you have any questions, just let us know. We can communicate over this bug report, or over the dsdp-tm-dev mailing list.
Martin, I'm working on the preliminary EFS implementation for WebDAV right now. This is going to build off of the Jakarta Slide WebDAV client. Currently, I'm getting around bug 181460 by just using linked folders to explore WebDAV resources. I hadn't quite gotten to the point of storing credentials (currently I'm just embedding them in the URI) so I'll have to look into RSE to see if we can get this to work. Once I get this stuff checked into CVS I'll let you know as well. --reid
Yes, managing the credentials goes beyond the plain EFS API -- having it embedded in the URI works fine for testing but isn't possible in real world because the URIs are stored in plaintext in the .project file for linked resources. Bug 181460 is mostly due to bug 181998 in the Platform, which should not be an issue for you if you manage to keep your EFS provider without any dependencies to the Resources plugin. I'm looking forward to getting your notice. Thanks!
Has there been any progress on this WebDAV EFS client? The Wiki page does not seem to have been updated lately.
As the WebDAV EFS client is a Google Summer of Code Project, I'm very confident that we will see something finished when the SoC project is done. But we'll likely not see any intermediate stages unless Reid decides he wants to share something with the community early.
(In reply to comment #7) > But we'll > likely not see any intermediate stages unless Reid decides he wants to share > something with the community early. Note that we are in the process of 'committerizing' Reid for the Eclipse SoC project. Once this is finished, we can start the IP process to get approval for checking in the code to the Eclipse SoC CVS.
Martin, I have a quick question. WebDAV locations are often (I'd even say usually) directories on a server (aka. foo.bar.com/dav). When I create a connection I get the new connection wizard page that has the 'Host name:' field. I'd like to be able to enter a host with a folder name that would be the root (foo.bar.com/dav). This would then enable foo.bar.com/dav to be stored in the SystemSignonInformation class and be passed around by RSE's normal mechanisms. However, if you add a directory here, SystemConfigurationForm.run(IProgressMonitor) fails when it tries to verify that foo.bar.com/dav is a valid host. Could run do something like this instead? URL url = new URL(currentHostName); InetAddress.getByName(url.getHost()); This may not be optimal because the java URL class requires a protocol description as well (presumably you don't want to have to specify this), but it does enable a folder name to be added to the host string. What would you recommend to enable DAV hosts to be rooted not at a host-level but at a host/folder level?
Also, why was this assumption made in FileServiceSubSystem.getUserHome(): @return The IRemoteFile that is the user's home directory on this remote file system. The remote file system is assumed to have a concept of a home directory. This assumption doesn't hold true for WebDAV file systems. This method also makes this call-chain: if (!userHome.getParentPath().equals(".")) //$NON-NLS-1$ This can result in a NullPointerException as getParentPath() is allowed to return null if userHome.isRoot() returns true.
(In reply to comment #9) Hello Reid, I think that your suggestion of using an URL instead of the host IP in the new connection wizard is a bit against the philosophy of RSE. In RSE, we have a remote "system" (the host) which may have multiple subsystems. The file subsystem, based on WebDAV, would just be one of them, with a remote shell, remote processes or whatever else being possibly other subsystems. That being said, I'd think a correct solution is as follows: * Remote system stores the hostname/ip address only. * WebDAV subsystem stores the "root folder" or root URL in its properties (as an RSE PropertySet). * This will be hard to set up for a user, with the default wizard. Therefore, create a "WebDAV Only" systemType and register a specialized wizard for WebDAV Only, see http://dsdp.eclipse.org/help/latest/topic/org.eclipse.rse.doc.isv/reference/extension-points/org_eclipse_rse_ui_newConnectionWizards.html * The specialized WebDAV wizard can have a single control for the URL as you propose, and automatically fills in the host IP into the system and the root folder (or URL) into the WebDAV subsystem. (In reply to comment #10) Yes, the concept of a home directory is kind of Legacy. I assume it's being used in order to support the RSE "My Home" filter such that users have one default filter pointing to the "most natural" directory on the remote. For WebDAV, I'd consider the "most natural" directory the root folder of your WebDAV share. The Javadoc of getUserHome() should perhaps be amended in order to clarify this concept. Many FTP servers treat the initial directory that you get to after login as the home, and often this is the root directory ("/"). Interestingly, I have still never seen the NPE that should occur if you are right. What you are describing sounds like a bug, I have no idea why it checks whether parent of home is ".", and I agree that it should check for null. Could you file a separate bug for that one?
It looks like the SoC Webdav project is finished: http://wiki.eclipse.org/WebDAV_EFS_Implementation Reid are you going to pursue the work for integrating WebDAV with RSE? Has any effort been made to get the WebDAV library you're using into Eclipse Orbit? Did you like the Jakarta Slide library for WebDAV such that we should make such an effort for the Ganymede train (note that cutoff date is Jan.31!) http://jakarta.apache.org/slide/webdav-client.html A different way to get WebDAV into RSE might be to write a generic file service that bridges to any existing EFS implementation. Another such "bridging" file service could bridge to any ECF file service implementation.
Just found this on Slide: "As of 2007-11-03, the Slide project is retired. This site is kept online for archiving purposes. If you are looking for a WebDAV client or a server-side Content Repository, please consider the Apache Jackrabbit project as an alternative." http://jackrabbit.apache.org/ http://jackrabbit.apache.org/doc/components/webdav.html From Commons VFS, the WebDAV component is currently in a sandbox and thus not being released (although Commons VFS does not seem to do any releases anyways): http://commons.apache.org/vfs/filesystems.html that one also seems to be based on Slide, and jdom.org JDom (for WebDAV 2.2+) so I'm not sure if it would be an option in terms of licensing anyways: http://commons.apache.org/vfs/download.html
I just saw that note about Slide and Jackrabbit in the past 10 days; I'm going to look into switching to Jackrabbit to see if I can get my implementation to work with that.
Thanks Reid. When do you think you might have more information? If we want to consider providing WebDAV support as part of Eclipse Ganymede, we need to enter the CQs for the 3rd party libs we need by Jan.31 -- in case of Jackrabbit, that would be CQs for 1. Jackrabbit-webdav 2. Jackrabbit-common 3. Slf4j I'd make the effort of filing these CQs only if there is a realistic chance to get WebDAV for Ganymede. Note that I'd be looking at putting these libs into the Orbit project, so if any other project just needs the plain WebDAV libs they would have them available fairly easily.
(In reply to comment #15) > I'd make the effort of filing these CQs only if there is a realistic chance to > get WebDAV for Ganymede. Note that I'd be looking at putting these libs into > the Orbit project, so if any other project just needs the plain WebDAV libs > they would have them available fairly easily. Sorry for not getting back to you in time; I've been working with Jackrabbit and have made a little progress but I wouldn't be able to speculate if it would be done or not. The webdav bits of jackrabbit are sparsely documented and it's likely I will run into problems that are difficult to solve along the way. Some example code would go a long way here but I haven't been able to find any (other than the one example in the javadoc).
Is there any update or upcoming plans on this issue? Thanks
As per bug 311859, there seems to be fresh interest in an Eclipse Webdav connector in the e4 Semantic File System (SFS) project.
