Resource Deltas for External Folders

Problem Summary

The resources plug-in broadcasts resource change events for files and folders in the workspace. This allows clients to react to changes that occur in those resources, and in the underlying file system. There is no way to receive resource change events for files and folders in the file system that do not belong to the workspace.

In the Java development tools, there are scenarios where a client wants to add folders outside the workspace to a build path of a Java project. This is not currently supported because there is no way to incrementally track changes to those external folders during a build. This is acceptable if the contents of the external folders never change, but will not be acceptable for end users when the folders are modified. The expectation is that the Java builder will do the right thing, and react to changes in the external folders.

The generally recommended solution for developing against external folders is to add a linked resource that refers to the external folder. This reifies the external folder as an IResource, allowing resource deltas to be produced, and the incremental builder to react accordingly. This solution is not adequate for clients using dynamic class-path containers that frequently change. Each change to the container would require adding or removing linked resources, causing the project description file to be modified (see bug 46668 for a similar problem with project references). Another general problem with adding a link to the project using the external folder is that it can create duplication in the resource tree. If there are 20 projects in the workspace that are compiled against the same external folder, 20 links, and 20 corresponding IResource sub-trees would be required.

One notable example of this requirement comes from plug-in developers using EMF-generated plug-ins. In this scenario, the developer uses two workspaces - a base workspace that contains the plug-ins that are generating the model, and a target workspace that contains the generated model. In some cases there is a need to compile the plug-ins in the target workspace against plug-ins in the base workspace (see bug 109137 for more details).

Potential Solutions

To avoid problems with duplicates in the resource tree, we stated that one project will be used as the library project. This project will be used as a container for links to external resources.

So to create or find a resource, we have to use such calls

IFolder folder = ResourcePlugin.getWorkspace().getRoot().getProject([theNameOfTheProject]).getFolder([idOfTheLink]);
folder.createLink([URI], IResource.NONE, null);

The only issue here is to create a unique id/name for the linked resource in the tree. Hashed URIs can be used.

The only request to the Resources is to hide such a folder to prevent users from playing with it. To see the progress for the hidden projects, see bug 210770

References

Bug 8655 DCR - Support for external class folders

Bug 77113 - Adding a directory-pointing variable to the project build path

Bug 81402 - Allow external classfolders from a container

Bug 109137 - Support compiling runtime workspace plugins against the launching workspace

Bug 182537 - Enhance classpath container to support external class folders