Jump to: navigation, search

Difference between revisions of "Workspace4.0"

m (Decouple Workspace from Client/UI)
(Flexible Project Organization)
Line 32: Line 32:
 
== Flexible Project Organization ==
 
== Flexible Project Organization ==
  
(see bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 35973])
+
Although the Eclipse project model has evolved over the lifespan of Eclipse, there are still several restrictions (see bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 35973]). Here is a list of some things that are not currently supported by the Eclipse Project model.
  
sharing of settings above the project level but below the workspace level (or through project associations as indocated in bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=202263 202263].
+
* sharing of settings above the project level but below the workspace level (or through project associations as indicated in bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=202263 202263].
 
+
* repository root above the project level but below the workspace level
repository root above the project level but below the workspace level
+
* separate name spaces within a single workspace to support development on multiple project versions (or would this be solved by support for multiple workspaces). Another aspect of this is to be able to easily identify, when multiple copies of the same project are available, the desired instance of a Java class.
 
+
* configure location of project meta-data either at the workspace level or at some level above the project(bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=78438 78438])
separate namespaces within a single workspace to support development on multiple project versions, for example
+
* Support scenario where two source folders within a single project can have a one way dependency (comment 54 of bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 35973])
 
+
* Ensure Maven2 is well supported. This will most likely involve support for nested projects in some form.
isolate sets of projects within a single workspace (although multiple workspace support is similar) so that builds and searches and be localized to a single set (or, it is easier to identify what set a particular java clas is found in, for instance)
+
 
+
configure location of project meta-data either at the workspace level or at some level above the project(bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=78438 78438])
+
 
+
Ensure Maven2 is well supported
+
 
+
Support scenario where two source folders within a single project can have a one way dependency (comment 54 of bug 35973)
+
  
 
== Resource Links ==
 
== Resource Links ==
  
 
repository root at the link level
 
repository root at the link level

Revision as of 10:37, 11 September 2007

This page describes some ideas we have for the Workspace components in Eclipse 4.0.

Disclaimer: What follows is not to be considered a commitment to address any of the mentioned issues in 4.0. It is only meant as a place to discuss the possibilities.

Eclipse File System

Push Down IResource functionality

The Eclipse File System (EFS) was introduced in Eclipse 3.2 and is used as the file abstraction on which the IResource model is based. There are other facilities available at the IResource level that could be pushed down to the EFS level, including:

  • local history
  • editor associations 120602
  • session and persistent property caches
  • deltas/change notification
  • repository providers
  • compare

Transaction Support

In addition, it would be nice to have transaction support at the EFS level

Decouple Workspace from Client/UI

Currently, the Eclipse workspace and its related facilities are run in the same executable as the customers of the workspace including the UI. We would like to investigate the possibility of decoupling the workspace functionality from its clients in order to support the following things

  • Support access to multiple workspaces simultaneously. Whether being run in the same executable or a separate process, it would be desirable to work with multiple workspaces within a single client UI without suffering the overhead of the current Switch Workspace operation.
  • Support remote workspaces (e.g. remote build and search). In some cases, the file resources being worked on are not located on the client machine. In these cases, it would be beneficial to also have workspace related functionality, such as build and search, run on the server where the workspace resides.
  • Decouple the concept of the workspace w.r.t the application from the concept used by the Resources plug-in. Currently, the workspace concept is overloaded to mean both the data area for the running application and the default root for projects.

Support for multiple workspaces also has the attribute that it allows developers to divide their work into isolated units (i.e. a change in a particular workspace would only need to build the projects in that workspace.

Flexible Project Organization

Although the Eclipse project model has evolved over the lifespan of Eclipse, there are still several restrictions (see bug 35973). Here is a list of some things that are not currently supported by the Eclipse Project model.

  • sharing of settings above the project level but below the workspace level (or through project associations as indicated in bug 202263.
  • repository root above the project level but below the workspace level
  • separate name spaces within a single workspace to support development on multiple project versions (or would this be solved by support for multiple workspaces). Another aspect of this is to be able to easily identify, when multiple copies of the same project are available, the desired instance of a Java class.
  • configure location of project meta-data either at the workspace level or at some level above the project(bug 78438)
  • Support scenario where two source folders within a single project can have a one way dependency (comment 54 of bug 35973)
  • Ensure Maven2 is well supported. This will most likely involve support for nested projects in some form.

Resource Links

repository root at the link level