Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Resource Deltas for External Folders"

(References)
(Plan of Action)
Line 11: Line 11:
 
== Potential Solutions ==
 
== Potential Solutions ==
  
== Plan of Action ==
+
== Potential Solutions ==
 +
 
 +
It's just a proposal, so feel free to add comments. Please add your name next to your comment,
 +
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>
 +
public interface IWorkspaceRoot extends IContainer, IAdaptable {
 +
 
 +
...
 +
 
 +
public IFolder getExtenalFolder(IProject libraryProject, URI location, int updateFlags,
 +
IProgressMonitor monitor) throws CoreException;
 +
}
 +
</pre></code>
 +
 
 +
or
 +
 
 +
<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 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 ==

Revision as of 10:41, 15 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

Potential Solutions

It's just a proposal, so feel free to add comments. Please add your name next to your comment, 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

public interface IWorkspaceRoot extends IContainer, IAdaptable {

...

public IFolder getExtenalFolder(IProject libraryProject, URI location, int updateFlags, 
IProgressMonitor monitor) throws CoreException;
}

or

public interface IWorkspaceRoot extends IContainer, IAdaptable {

...

public IFolder getExtenalFolder(IContainer libraryContainer, URI location, int updateFlags, 
IProgressMonitor monitor) throws CoreException;
}

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 IWorkspaceRoot#getExtenalFolder(...) is called.

  • Getting an external folder by calling IWorkspaceRoot#getExtenalFolder(...)

A linked resource to external folder will be created (if doesn't exist already) and returned.

  • Releasing library container

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

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

Back to the top