Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Team Logical Model Support
The following paragraph, taken from the Eclipse 3.2 plan, describes the motivation for the logical model integration support that was added in Eclipse 3.2.
The Eclipse Platform supports a strong physical view of projects, files, and folders in the workspace. However, there are many situations where a physical view is not the most salient or useful for many purposes. In some cases, multiple distinct objects happen to be stored in a single file, like an archive. Conversely, in other cases, something that is logically a single object is stored across multiple files. This discrepancy between logical and physical creates problems for common operations such as searching, comparing, and versioning, which need to work in the physical realm. Eclipse should support some way of mapping between a logical view and the physical organization of files on disk.
At the beginning of the 3.2 development cycle, we captured the requirements from several clients in a requirements document.
The following points summarize the features provided by the logical model support.
Maintaining Workspace Consistency: Operations performed directly on resources may have undesirable side effects on model elements that are persisted in, or are otherwise associated with, those resources. Clients can use the ResourceChangeValidator to validate that changes to resources will not have undesirable side effects on models while models can implement the ModelProvider#validateChange method to validate a resource change.
Team Operations and Decorations: It has always been possible to have team operations and decorations appear on model elements that have a one-to-one relationship by adapting the model element to the corresponding IResource. It is now possible to have operation and decorations appear on model elements that have more complex relationships to resources by adapting a model element to a ResourceMapping.
Semantic Merges of Model Elements: Model Providers can participate in headless merges by associating an IStorageMerger with a particular file type if there is a one-to-one correspondence between model elements and resources. For more complex relationships, Model Providers can adapt their ModelProvider to an IResourceMappingMerger to have access to the full context of the merge operation.
Model participation in team viewers: The team views now make use of the Common Navigator framework. By extending a Common Navigator extension point and a Team extension point, and supplying a content provider and a label provider, a Model Provider can appear in the team views. With a few more additonal steps, it is also possible to provide Merge Preview support for a model.
Remote Discovery: Model Providers can participate in Remote Discovery through the use of the Team ProjectSetCapability class to obtain an URI from project set entries. This URI can then be used with the Eclipse File System API to access remote contents.
Model History: Model Providers can access individual File History through the FileHistory API, and present a model history as they wish in a custom History Page which get displayed in the History View.
The details of how to make use of these features are outlined in the Repository Provider Roadmap and the Model Provider Roadmap.
Links
These roadmaps illustrate the work that a repository provider or model provider would need to do to leverage the logical model integration support. The help documentation of Eclipse ships with modified versions of these pages. The above linkes will be updated to point to the help documentation once it is available one line.
This document was written during the 3.2 development cycle as a means of communicating to clients what the status of the work was. The first section summarizes the solution areas and the rest outlines solution specifics. However, the solution roadmaps mentioned above are more up-to-date.
This document capture the requirements from various model clients.