Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Resource Deltas for External Folders"
m (→Solution 2) |
(→Potential Solutions) |
||
| Line 11: | Line 11: | ||
== Potential Solutions == | == 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 | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
<code><pre> | <code><pre> | ||
| − | + | IFolder folder = ResourcePlugin.getWorkspace().getRoot().getProject([theNameOfTheProject]).getFolder([idOfTheLink]); | |
| − | ... | + | folder.createLink([URI], IResource.NONE, null); |
| − | + | ||
| − | + | ||
</pre></code> | </pre></code> | ||
| − | + | The only issue here is to create a unique id/name for the linked resource in the tree. We can use hashed URIs. | |
| − | The | + | 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 we can just use "External Plug-in Libraries" project. |
== References == | == References == | ||
Revision as of 09:04, 22 November 2007
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. We can use hashed URIs.
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 we can just use "External Plug-in Libraries" project.
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