We're at a critical juncture in the evolution of the CDT. Everything has been going so good lately, with tons of indexer and build improvements, that I guess we were due for a bit of a crisis. The issue we are grappling with is how to use the CDT with projects that have source files sitting on a remote server, possibly across the Internet somewhere. It's a tough environment that will definitely stretch Eclipse and the CDT if we are ever successful in making it work well.
The solution I've been hoping to push is to use EFS to access those files and, in theory, the CDT should just work. What's EFS? Well, it's the Eclipse File System, which provides a layer of abstraction at the same level as java.io.File, but allows different implementations. Using the right IResource APIs and URIs instead of IPath, and everything should work. It seems designed to meet our needs.
I managed to build a FileSystem using FTPClient from Apache's common.net. My test is to run it against the ftp server on the CDT build machine at Eclipse. Saving files is a bit slow, and I guess that's to be expected and we can probably introduce some caching and worker threads to at least get it off the UI thread. I imagine RSE does this already and will need to take a closer look at their EFS implementation to see if it would work better.
The bigger issue is the number of instances where plug-ins are assuming IPath works and IResource.getLocation() works. And I kind of knew that going into it, that we'd have some work in the CDT to solve this, and that proved to be true. So I tried a General project and text files worked fine. So I though I'd try something more involved. How about a Ant build.xml file. Well, there again, massive NPEs because the build.xml editor and the AntModel assumes IPath to work. Not only that, they use java.io.File to get at the file. Ouch.
It is pretty clear that little work has been done to try out a real EFS implementation as backing for IResources, or at least not enough work. My feeling is that this remote project idea must transcend the CDT, and we've even thought about starting a new Eclipse project to focus on it. It's clear there is a lot of work to do and we need to start organizing if we really want to make EFS remote projects work.
Yes, I have -- I've even written an article on how to write your own implementation (http://www.eclipsezone.com/articles/efs/).
ReplyDeleteYou're right -- there's a lot of places that assume the existence of a Location instead of LocationURI, and it's only by people trying these cases (and raising bugs) that they'll get fixed. I found a few of them (subsequently fixed) but there's many more out there.
It was even noted in the 3.2 new and noteworthy:
. Resources are no longer necessarily in the local file system
What is affected:Clients of the IWorkspace API that assume resources are stored in the local file system.
"Description: Prior to Eclipse 3.2, each existing IResource had a corresponding file or directory in a file system accessible by java.io.File. In Eclipse 3.2, support was added for creating resources whose contents are stored in an arbitrary backing file system. Resources using this support can no longer be represented directly as a java.io.File.
Action required: The old method IResource.getLocation() returns the local file system path of a resource. This method returns null for resources that are not stored in the local file system. Most callers of getLocation() did so in order to obtain an instance of java.io.File, which can no longer be used for resources that are not stored in the local file system."
The problem was, no-one's actually tried to do huge amounts of development with a non-file EFS based system and therefore they haven't found these issues.
But having said that, I've used a custom EFS implementation for custom languages (i.e. not Java/ant) and so haven't run into the specific issues you've noted with the Ant editor. The EFS implementation does work, and is very useful -- but not all code followed the 3.2 guidelines, and you've run into that.
I recommend raising bugs about the issues that you've had so that they end up working for 3.3. I agree that there wasn't enough time spent on verifying EFS to ensure that there weren't these issues, but let's aim to make 3.3 a better place.
Has there been any updates to this? Do we support EFS under CDT?
ReplyDelete