Jump to: navigation, search

Difference between revisions of "Resource Deltas for External Folders"

(Potential Solutions)
(Potential Solutions)
 
(10 intermediate revisions by the same user not shown)
Line 11: Line 11:
 
== Potential Solutions ==
 
== Potential Solutions ==
  
=== Solution 1 ===
+
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.
  
It's just a proposal, so feel free to add comments. Please add your name next to your comment,
+
So to create or find a resource, we have to use such calls
it will help to find the guilty.
+
 
+
==== Library container ====
+
 
+
The library container contains linked resources to external folders. Linking an external resource  
+
using the library container has the following advantages
+
 
+
*an external folder is added to the resource tree once
+
*metadata of a project that want to use external resource is not modified
+
 
+
==== Proposed API ====
+
 
+
I'm considering two candidates for API
+
  
 
<code><pre>
 
<code><pre>
public interface IWorkspaceRoot extends IContainer, IAdaptable {
 
  
...
+
IFolder folder = ResourcePlugin.getWorkspace().getRoot().getProject([theNameOfTheProject]).getFolder([idOfTheLink]);
 +
folder.createLink([URI], IResource.NONE, null);
  
public IFolder getExtenalFolder(IProject libraryProject, URI location, int updateFlags,
 
IProgressMonitor monitor) throws CoreException;
 
}
 
 
</pre></code>
 
</pre></code>
  
or
+
The only issue here is to create a unique id/name for the linked resource in the tree. Hashed URIs can be used.
 
+
<code><pre>
+
public interface IWorkspaceRoot extends IContainer, IAdaptable {
+
 
+
...
+
 
+
public IFolder getExtenalFolder(IContainer libraryContainer, URI location, int updateFlags,
+
IProgressMonitor monitor) throws CoreException;
+
}
+
</pre></code>
+
 
+
The question here is if only projects can be library containers. I think that we can
+
treat folders as the containers as well.
+
 
+
==== Lifecycle of library container and linked resources ====
+
 
+
* Library container creation
+
The library container has to be created by the user or when <code>IWorkspaceRoot#getExtenalFolder(...)</code> is called.
+
 
+
* Getting an external folder by calling <code>IWorkspaceRoot#getExtenalFolder(...)</code>
+
A linked resource to external folder will be created (if doesn't exist already) and returned.
+
  
* Releasing library container
+
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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=210770 bug 210770]
The library projects can be removed either by the workspace or by the user of the project. They can be removed when the workspace is being closed. However I would make it a user responsibility to control the library containers' lifecycle. The issue is e.g. a project which is a library container and a regular project in the same time.
+
  
 
== References ==
 
== References ==

Latest revision as of 08:06, 27 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. 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