Resource Deltas for External Folders
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).
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. The solution is to have a similar API to the one for team resources. Or "External Plug-in Libraries" project can be used.
Suggested API (if "External Plug-in Libraries" is not acceptable)
. This method won't return hidden projects. To have a method that returns all projects, we can consider such APIIProject#setHidden(boolean); IProject#isHidden() return boolean; </code>
The hidden flag will affect <code>IWorkspaceRoot#getProjects()