| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title>Model Roadmap for Logical Model Integration</title> |
| </head> |
| <body> |
| <table width="100%" cellpadding="2" cellspacing="5" border="0"> |
| <tbody> |
| <tr> |
| <td bgcolor="#0080c0" valign="top" align="left"> <b><font |
| face="Arial,Helvetica" color="#ffffff"> Eclipse 3.2 - Model Roadmap for Logical |
| Model Integration</font></b></td> |
| </tr> |
| </tbody> |
| </table> |
| <h1>Model Roadmap for Logical Model Integration</h1> |
| <p>Version 3.2 M5</p> |
| <p>The <a |
| href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/team3.2/model-integration-proposals.html">Proposed |
| Support for Logical Model Integration</a> document outlines all the areas that |
| are targeted to be addressed in 3.2 related to logical model integration support |
| in Eclipse. The purpose of this document is to describe how model providers |
| can make use of this API. </p> |
| |
| <p>Here is a list of what model providers can do to take advantage of the this support:</p> |
| |
| <ol> |
| <li>Use the <a href="#SaveableModels">ISaveableModel</a> API to have more control over the save lifecycle of model elements.</li> |
| <li>Extend the <a href="#Problems">org.eclipse.ui.ide.markerSupport</a> extension point to add modle specific catebtories to the |
| problems view.</li> |
| <li>Use the <a href="#CommonNavigator">Common Navigator</a> framework to create model-based viewers.</li> |
| <li>Adapt model elements in model views to <a href="#ResourceMapping">ResourceMapping</a> in order |
| to allow resource based operations to appear on your model elements.</li> |
| <li>Register a <a href="#ModelProvider">ModelProvider</a> |
| to ensure that your model is consulted when operations are performed on the resources related to your model.</li> |
| <li>Use the <a href="#ChangeValidation">ResourceChangeValidator</a> when performing operations on resources in order to ensure |
| that any potential side effects on the model elements related to those resources are made known to the user. |
| <li>Implement an <a href="#AutoMerge">IResourceMappingMerger</a> in order to participate in headless merges that involve the |
| resources relatd to yur model.</li> |
| <li>Register a <a href="#TeamContent">teamContentProvider</a> in order to participate in Team viewers such as merge previews.</li> |
| <li>Provide an <a href="#History">IHistoryPageSource</a> to show logical model history in the Team history view.</li> |
| <li>Use the <a href="#RemoteBrowsing">Eclipse File System</a> API to access the remote state of model projects.</li> |
| <li>Use the <a href="#Decoration">SynchronizationStateTester</a> API to ensure proper |
| decoration of modle elements that do not have a one-to-one mapping to resources. |
| </ol> |
| |
| <p>The following sections describe each of these points in more detail. |
| A pointer to a simple <a |
| href="#Example">Library example</a> is also provided.</p> |
| |
| <h2><a name="SaveableModels"></a>Saveable Lifecycle</h2> |
| |
| <p>Not all model providers want the save lifecycle of their models tied to an editor. |
| The following support has been added to allow models to control the save lifecycle: |
| <ul> |
| <li>ISavableModel is used to represent a model that is atomically savable |
| <li>ISavableModelSource is used to return one or more savable models. View parts that |
| contain saveable models should implement this interface. |
| </ul> |
| <p>These interfaces are used by the workbench in the following way: |
| <ul> |
| <li>When a Save operation is performed, the active view is queried for its active models and those are saved. This allows views to decide whether a save in the view should save all models or only those that are selected. |
| <li>When a view or editor is closed, the workbench queries the view for any savable models. |
| If it finds some, it looks to see if there are any other views or editors that contain that model. |
| <ul> |
| <li>The user is prompted to save any models that are not contained in other views |
| <li>For models that are contained in other views, no prompting occurs. |
| </ul> |
| <li>On shutdown, the workbench prompts for any unsaved models |
| </ul> |
| |
| <h2><a name="Problems"></a>Problems View</h2> |
| |
| <p>The following changes have been made to the problems view: |
| <ul> |
| <li>Declarative filters and grouping has been added that allows problems to be grouped by categories appropriate for the problem type. |
| This is provided by the <em>org.eclipse.ui.ide.markerSupport</em> extension point in the <em>org.eclipse.ui.ide</em> plug-in. |
| <li>The name, path and location labels for each problem can be tailored to whatever is appropriate for the originating model. |
| The property keys for tailoring these fields are: |
| <ul> |
| <li>IMarker.LOCATION |
| <li>MarkerViewerUtil.PATH |
| <li>MarkerViewerUtil.NAME |
| </ul> |
| </ul> |
| |
| <h2><a name="CommonNavigator"></a>Common Navigator</h2> |
| |
| The Common Navigator has been made available in 3.2. There is no plan to provide a |
| Common view for all models to appear in but the framework is available for logical |
| models to use and the Team support for logical models uses the framework to show the |
| synchronization state of logical models involved in merges. The Common Navigator is |
| contained in the <em>org.eclipse.ui.navigator</em> plug-in. There is also an <em>org.eclipe.ui.navigator.resources</em> |
| that contains a potential replacement for the Resource Navigator. |
| |
| <h2><a name="ResourceMapping"></a>Resource Mappings</h2> |
| |
| <h3>The Basic Resource Mapping API</h3> |
| <p>The resource mapping API is purposely |
| simple with logical model manipulations omitted. A client can't use this interface |
| to display logical models or gain any interesting additional knowledge about |
| it. It's purpose is simply to map one or more model elements to workspace resources. |
| </p> |
| <p>The API consists of the following classes: </p> |
| <ul> |
| <li><strong>ResourceMapping</strong>: The Class to which logical model elements |
| adapt to indicate that the model corresponds to a set of resources in the |
| workspace. The complete <code>ResourceMapping</code> class can be viewed <a |
| href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.resources/src/org/eclipse/core/resources/mapping/ResourceMapping.java?rev=HEAD&content-type=text/vnd.viewcvs-markup">here</a>. |
| The methods of interest are: |
| <ul> |
| <li><code>Object getModelObject()</code>: The model object from which the |
| mapping was derived (or adapted).</li> |
| <li><code>ResourceTraversal[] getTraversals(ResourceMappingContext, IProgressMonitor)</code>: |
| The resource traversal that cover the resources that constitute the model |
| object.</li> |
| </ul> |
| </li> |
| <li><strong>ResourceTraversal</strong>: A <a |
| href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.resources/src/org/eclipse/core/resources/mapping/ResourceTraversal.java?rev=HEAD&content-type=text/vnd.viewcvs-markup"><code>ResourceTraversal</code></a> |
| contains a set of resources and a depth flag that indicates the depth to which |
| the resources in the traversal are associated with the originating model object. |
| Resource traversals are provided to a client by a resource mapping in order |
| to describe the contents of a model in such a way that the client (e.g. a |
| repository provider) can perform its operations in as efficient a means as |
| possible. Methods of interest are: |
| <ul> |
| <li><code>getResources()</code></li> |
| <li><code>getDepth()</code></li> |
| </ul> |
| </li> |
| <li><strong>ResourceMappingContext</strong>: a context that is provided to the |
| resource mapping by the client when obtaining traversals. This context allows |
| the logical model to determine what the remote state of the model is so that |
| the proper resources can be covered by the resource traversals returned by |
| the resource mapping. The use of the<code> <a |
| href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.resources/src/org/eclipse/core/resources/mapping/ResourceMappingContext.java?rev=HEAD&content-type=text/vnd.viewcvs-markup">ResourceMappingContext</a></code> |
| and<code> <a |
| href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.resources/src/org/eclipse/core/resources/mapping/RemoteResourceMappingContext.java?rev=HEAD&content-type=text/vnd.viewcvs-markup">RemoteResourceMappingContext</a></code> |
| is a bit more complicated and is described <a |
| href="#ResourceMappingContext">later</a>.</li> |
| </ul> |
| <p>There are two types of plugins that should be interested in resource mappings. |
| Those who provide a model that consists of, or is persisted in, resources in |
| the workspace and those that want to perform operations on resources. The former |
| is covered in the next section while the later ius covered in a separate |
| <a href="repoRoadMap.html">Document</a></p> |
| |
| <h3>Adapting a Model to a ResourceMapping</h3> |
| |
| <p>Plugins that adapted their model objects to <code>IResource</code> in order |
| to get resource specific actions shown in the context menu can now adapt to |
| <code>ResourceMapping</code> if a richer description of how the object adapts |
| to resources is beneficial. However, they are not required to do so if there |
| is no benefit. For instance a Java compilation unit (i.e. *.java file shown |
| in a JDT view) that now currently adapts to <code>IFile</code> need not adapt |
| to <code>ResourceMapping</code> since nothing is gained. However, a Java package |
| should adapt to <code>ResourceMapping</code> in order to indicate that the package |
| consists of only the files in the corresponding folder and not the subfolders.</p> |
| <p>The preferred way to adapt model elements to a resource mapping is to use an |
| adapter factory. The following is the XML markup for contributing an adapter |
| factory in a plugin manifest. </p> |
| <pre style="background-color: rgb(204, 204, 255);"> <extension<br> point="org.eclipse.core.runtime.adapters"><br> <factory<br> class="org.eclipse.example.library.logical.AdapterFactory"<br> adaptableType="org.eclipse.example.library.Book"><br> <adapter type="org.eclipse.core.resources.mapping.ResourceMapping"/><br> </factory><br> <factory<br> class="org.eclipse.example.library.logical.AdapterFactory"<br> adaptableType="org.eclipse.example.library.Library"><br> <adapter type="org.eclipse.core.resources.mapping.ResourceMapping"/><br> </factory><br> ...<br> </extension></pre> |
| <p>The adapter factory implementation would look something like this:</p> |
| <pre style="background-color: rgb(204, 204, 255);">public class AdapterFactory implements IAdapterFactory {<br> public Object getAdapter(Object adaptableObject, Class adapterType) {<br> if((adaptableObject instanceof EObject) && adapterType == ResourceMapping.class) {<br> return new EObjectResourceMapping((EObject)adaptableObject);<br> }<br> return null;<br> }<br><br> public Class[] getAdapterList() {<br> return new Class[] {ResourceMapping.class};<br> }<br>}</pre> |
| <p>Model objects must implement the <code>IAdaptable</code> interface. When they |
| do so, they must ensure that the Platform adapter manager is consulted. This |
| can be done by either subclassing <code>PlatformObject</code> or by using the |
| following line of code:</p> |
| <blockquote> |
| <p><code>Platform.getAdapterManager().getAdapter(Object, Class)</code></p> |
| </blockquote> |
| <p>The above is the preferable approach. However, the model object can implement |
| the IAdaptable interface and provide a <code>getAdapter(Class)</code> implementation |
| that creates returns an instance of <code>ResourceMapping</code> explicitly |
| when asked for one. This is a more straightforward approach but the least desirable |
| as the model must have explicit knowledge of the adaptation to resources.</p> |
| <p>In some cases, the provider of a logical model may not want their model to |
| adapt to <code>IResource</code> in every context or may want the object to adapt |
| differently for object contributions than for other contexts. The workbench |
| UI provides a special intermediate adapter API, <code>IContributorResourceAdapter</code>, |
| for this purpose. When objects are being adapted to <code>IResource</code> in |
| the context of object contributions, the workbench first tries to adapt the |
| resource to <code>IContributorResourceAdapter</code> before trying to adapt |
| to <code>IResource</code> directly. A new sub-interface of this interface, <code>IContributorResourceAdapter2</code>, |
| has been added which provides the same capability for <code>ResourceMapping</code>. |
| The only difference is that the model provider should register a factory for<code> |
| IContributorResourceAdapter</code> since the Workbench does an <em>instanceof</em> |
| check to see if the contributed adapter is also an instance of <code>IContributorResourceAdapter2</code>.</p> |
| <p>The implementation of the <code>ResourceMapping</code> subclass for a Java |
| package would look something like this.</p> |
| <pre style="background-color: rgb(204, 204, 255);">public class JavaPackageResourceMapping extends ResourceMapping {<br> IPackageFragment package;<br> ...<br> public getModelObject() {<br> return package;<br> }<br> public ResourceTraversals[] getTraversals(<br> ResourceMappingContext context, <br> IProgressMonitor monitor) {<br> return new ResourceTraversal[] { <br> new ResourceTraversal(<br> new IResource[] { package.getCorrespondingResource() },<br> IResource.DEPTH_ONE, IResource.NONE)<br> }<br> }<br>}</pre> |
| <p>This is a fairly straightforward mapping so the implementation is not complex. |
| The complexity of the resource mapping implementation will, of course, vary |
| from model to model. The <code>EObjectResourceMapping</code> example used above |
| is implemented in the example and has a more complicated implementation.</p> |
| |
| <h3><a name="ResourceMappingContext"></a>Resource Mapping Context</h3> |
| <p>One of the advantages of a Resource Mapping API is that it allows plug-ins |
| to implement any operations they desire in terms of resource mappings (e.g. |
| CVS update, CVS commit, CVS tag, dirty decoration, etc.). However, the API that |
| has been introduced so far deals only with the local state of the model. When |
| working with a model that may be shared between developers, you end up in a |
| situation where the remote state of the model (i.e. the state of the model that |
| another user has checked-in to the repository) may differ from the state in |
| the workspace. If you performed a CVS update, you would want the local state |
| of the model to match the remote state even if it meant that additional files |
| needed to be included or some files needed to be removed.</p> |
| <p>This is not an issue for some logical models. For instance, a java package |
| is a container visited to a depth of one, regardless of the remote state of |
| the model. Given this, a repository provider can easily determine that outgoing |
| deletions should be included when committing or that incoming additions should |
| be included when updating. However, the resources that constitute some logical |
| models may change over time. For instance, the resources that constitute a model |
| element may depend of the contents of a manifest file (or some other similar |
| mechanism). In order for the resource mapping to return the proper traversal, |
| it must access the remote contents of the manifest file (if it differs from |
| the local contents) in order to see if there are additional resources that need |
| to be included. These additional resources may not exist in the workspace but |
| the repository provider would know how to make sure they did when the selected |
| action was performed.</p> |
| <p>In order to support these more complex models, a <code>RemoteResourceMappingContext</code> |
| can be passed to the <code>ResourceMapping#getTraversals</code> method. When |
| a context is provided, the mapping can use it to ensure that all the necessary |
| resources are included in the traversal. If a context is not provided, the mapping |
| can assume that only the local state is of interest. </p> |
| <h4>When does a ResourceMapping need to worry about the RemoteResourceMappingContext?</h4> |
| <p>A <code>ResourceMapping</code> need only worry about a context supplied to |
| the <code>getTraversals</code> method in cases were the resources that make |
| up a model change over time and the relationship between the model and resources |
| cannot be described by a simple traversal that is guaranteed to encompass those |
| resources (and only those resources) that constitute the model. For example, |
| although the resources of a Java package may change over time, the package can |
| be described as a folder of depth of one so a resource mapping for java packages |
| would not ned to make use of the resource mapping context. </p> |
| <p>As a more complicated example, consider an HTML file that contains several |
| images. Let's make the assumption that any images references from an HTML file |
| are part of the model of that file. When updating the local contents of the |
| HTML file from a repository, the user would expect that any new images would |
| be included. The <code>getTraversals</code> method for a <code>ResourceMapping</code> |
| for the HTML file model would look something like this:</p> |
| <pre style="background-color: rgb(204, 204, 255);">public class HTMLResourceMapping extends ResourceMapping {<br> private HTMLFile htmlFile;<br> public ResourceTraversal[] getTraversals(ResourceMappingContext context, <br> IProgressMonitor monitor)<br> IResource[] resources = htmlFile.getResources();<br> if (context instanceof RemoteResourceMappingContext) {<br> // Look for any additional resources on the server<br> RemoteResourceMappingContext remoteContext = (RemoteResourceMappingContext)context;<br> IFile file = htmlFile.getFile();<br> if (remoteContext.hasRemoteChange(file, monitor)) {<br> IStorage storage = remoteContext.fetchRemoteContents(file, monitor);<br> IResource[] additionalResources = getReferences(storage.getContents());<br> resources = combine(resources, additionalResources);<br> }<br> if (remoteContext.isThreeWay() && remoteContext.hasLocalChange(file, monitor)) {<br> IStorage storage = remoteContext.fetchBaseContents(file, monitor);<br> IResource[] additionalResources = getReferences(storage.getContents());<br> resources = combine(resources, additionalResources);<br> }<br> }<br> return new ResourceTraversal[] { <br> new ResourceTraversal(resources, IResource.DEPTH_ZERO, IResource.NONE)};<br> }<br>}</pre> |
| <p>Notice that there are two sets of resources included in the model: those derived |
| from the local contents of the HTML file in the workspace and those obtained |
| from the contents of the remote file and base file. In either of these two sets, |
| there may be resources that do not exist in the workspace. For instance, the |
| local HTML file may contain a relative link to an image that does not exist |
| in the workspace. This resource should be included so that it will be fetched |
| if it exists remotely. As for the remote file, it may contain a new copy that |
| references additional images that should be fetched when the new remote contents |
| are downloaded.</p> |
| |
| |
| <h2><a name="ModelProvider"></a>Model Providers</h2> |
| |
| <p>Model providers are a means to group related resource mappings together. Here |
| is a link to the |
| <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.resources/src/org/eclipse/core/resources/mapping/ModelProvider.java?rev=HEAD&content-type=text/vnd.viewcvs-markup">ModelProvider</a> |
| class. This class serves three main purposes:</p> |
| <ol> |
| <li>From a model provider, clients can then obtain additional API pieces for |
| performing operations on a set of resource mappings using the adaptbale mechanism. |
| For example, the <code>IResourceMappingMerger</code> |
| for the model is obtained by adapting the modle provider.</li> |
| <li>Given a set of file-system resources, clients can query whether a model |
| provider has model elements persisted in those resources and, if it does, |
| obtain the set of resource mappings that describe the relationship.</li> |
| <li>For operations on a set of resources, the resource change validator |
| will query the model providers in order to determine if there are any potential |
| side effects of an operation that users should be made aware of. This is covered in a separate section |
| on <a href="#ChangeValidation">change validation</a>.</li> |
| </ol> |
| <p>The following is an example of a modelProvider extension definition.</p> |
| <pre style="background-color: rgb(204, 204, 255);"> <extension<br> id="modelProvider"<br> name="Library Example"<br> point="org.eclipse.core.resources.modelProviders"><br> <modelProvider<br> class="org.eclipse.team.examples.library.adapt.LibraryModelProvider"<br> name="Library Example"/><br> <extends-model id="org.eclipse.core.resources.modelProvider"/><br> <enablement> |
| <test property="org.eclipse.core.resources.projectNature" |
| value="org.eclipse.team.examples.library.view.nature" /><br> </enablement><br> </extension><br></pre> |
| <p>The <code>LibraryModelProvider</code> is a subclass of <code>ModelProvider</code>. |
| The enablement rule is used to match resources that the Library model persists |
| its model in. In the above example, the model provider will match any resource |
| in a project that has the library nature. </p> |
| <p>Once the model provider is defined, the <code>ResourceMapping#getModelProviderId()</code> |
| method should be overridden to return the id of the model provider.</p> |
| <pre style="background-color: rgb(204, 204, 255);"> public String getModelProviderId() {<br> return "org.eclipse.team.examples.library.adapt.modelProvider";<br> }<br></pre> |
| <p>To get the proper inverse mapping of resources to resource mapping for those |
| resources that match your provider's enablement rule, you should also override |
| one or both of the <code>getMapping</code> methods. The method that you need |
| to override depends on whether your model has elements that contain multiple |
| resources or not. If your model elements map to a single resource, you can override |
| the method that accepts a single<code>IResource</code> argument. Otherwise, |
| you will need to override the method that accepts an array of resources. Here's |
| an example using the single resource case.</p> |
| <p>The following example method wraps a library model file in an appropriate resource |
| mapping. It also wraps folders that contain files that are of interest to the |
| model provider.<br> |
| </p> |
| <pre style="background-color: rgb(204, 204, 255);">public class LibraryModelProvider extends ModelProvider {<br> public ResourceMapping[] getMappings(IResource resource, <br> ResourceMappingContext context, IProgressMonitor monitor) {<br> if (isModelFile(resource)) {<br> // Return a resource mapping on the file<br> return new LibraryResourceMapping(resource);<br> } if (containsModelFiles(resource)) {<br> // Create a deep resource mapping on the container<br> return new LibraryContainerResourceMapping(resource);<br> }<br> // The resource is not of interest to this model provider<br> return null;<br> }<br>}</pre> |
| <p>Clients can then access the model provider to determine whether the model providers |
| cares about the resources that are about to be operated on. The next section |
| describes API that will be provided to team operations that use the model provider |
| API to determine the complete set of resource mappings to be operated on when |
| a team operation is performed on a set of selected resources or model elements.</p> |
| |
| |
| <h2><a name="ChangeValidation"></a>Resource Change Validation</h2> |
| |
| <p>Operations performed on resources should be validated first to ensure that the user is awar of |
| any potential side effects. Here are the steps required to validate a resource change.</p> |
| <ol> |
| <li>Build up a description of the change using the <code>ResourceChangeDescriptionFactory</code>. The |
| factory produces an <code>IResourceDelta</code> that mirrors what the resulting resource delta will look |
| like once the operation is performed.</li> |
| <li>Validate the change using the <code>ResourceChangeValidator</code>. |
| The validator consults all the model providers that have registered an interest in the affected resources. |
| The result is one or more status that contain the id of the originating model and a description of the potential |
| side effetc of the operation on the model.</li> |
| <li>Make the user aware of any potential side effects from models that are unknown to the originator of the operation. |
| For instance, if a Jaa refactoring has received a side effect from the Java model, it can be ignored since |
| the refactoring understands the semantics of the Java model. However, if a side effect from the Library model |
| is returned, it should be made known to the user since Java has no knowledge of the Library model. |
| </li> |
| </ol> |
| |
| <h2><a name="AutoMerge"></a>Model-based Merging</h2> |
| |
| <p>When a Team provider is attempting a headless merge, it will do the following: |
| <ol> |
| <li>Obtain the resource mappings from the selected elements |
| <li>Determine the model providers involved using the ResourceMapping#getModelProvider() method. |
| <li>Expand the scope of the operation to include all necessary resource mappings. |
| <li>Build up a description of the synchronization state between the local and remote. This description is provided to the models through the |
| <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.core/src/org/eclipse/team/core/mapping/IMergeContext.java?rev=HEAD&content-type=text/vnd.viewcvs-markup">IMergeContext</a> |
| API. |
| <li>Adapt the model providers to <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.core/src/org/eclipse/team/core/mapping/IResourceMappingMerger.java?rev=HEAD&content-type=text/vnd.viewcvs-markup">IResourceMappingMerger</a>. |
| <li>Invoke the validateMerge method on each merger, passing in the synchronization description, to ensure there is not some condition that should prevent an attempted merge. |
| <li>Delegate the merge to the model mergers to perform the merge. |
| <li>Model providers can delegate the merge of individual files back to the Team provider if they only want to control the order of the merge or may perform the merge themselves and signal to the team provider when they are done. |
| </ol> |
| |
| <h2><a name="TeamContent"></a>Model Content in Team Operation Views</h2> |
| |
| <p>The display of model elements in the context of a Team operation is made possible by the Common Navigator framework. |
| <ul> |
| <li>Provide an extension of the org.eclipse.ui.navigator.navigatorContext extension. |
| <li>Provide an extension of the org.eclipse.team.ui.teamContentProviders extension point to associate the content provider with a model provider. |
| <li>Implement a content provider and label provider for the navigatorContent extension. It is best to subclass the Team/UI SynchronizationContentProvider and SynchronizationLabelProvider for this. They wrap existing content/label providers and handle interactions with the team provider such as sync state decoration and filtering based on sync state. |
| </ul> |
| <p>The above steps will allow models to appear in dialogs used by team operations. There are additional steps required to integrate into a merge preview. |
| <ul> |
| <li>Adapt the model provider to ICompareAdpater. This is done to allow the model to open model specific compare editors on model elements. |
| <li>Implement an action provider for the navigatorContent extension as a subclass of SynchronizationActionProvider. This will allow the model to register merge handlers that will be invoked when users perform merge operations on the model providers elements in the merge preview. |
| </ul> |
| |
| <h2><a name="History"></a>History View</h2> |
| |
| <p>The following improvements have been made in the area of file history and model element history: |
| <ul> |
| <p>The History view has been generalized to display the history of any object that adapts to an IHistoryPageSource. |
| Thus, model providers can render the history for their logical model elements. |
| <li>An IFileHistoryProvider API has been added for obtaining and querying the remote history of workspace files. |
| Logical models can obtain and interpret this history. |
| <li>A compare adapter will be provided to hook up the selection in an IHistoryPage to compare editors so that history pages can be reused in the context of compare operations. |
| </ul> |
| |
| <h2><a name="RemoteBrowsing"></a>Remote Browsing</h2> |
| |
| <p>The following has been provided to support remote browsing: |
| <ul> |
| <li>An Eclipse File System API has been introduced in the org.eclipse.core.filesystem plug-in. |
| <li>API has been added to the Team ProjectSetCapability to obtain the URI from project set entries. These URIs can be used to obtain a FileSystem for the purposes of browsing remote contents. |
| <li>Models that require an IResource base project can use the file system to create a team-private project. |
| <li>Methods have been added to the ProjectSetCapability for loading a URI as a project. |
| </ul> |
| |
| <h2><a name="Decoration"></a>Team State Decoration</h2> |
| |
| <p>Team decorations can be applied to model elements using ResourceMapping. |
| However, the Team decorator will not know when to update the decorations on model elements that do not have a one-to-one mapping to files. |
| The following support has been added to support label updates for this type of model element: |
| <ul> |
| <li>Model providers can use the SynchronizationStateTester class in their model views to interface with the Team decorators |
| in order to determine when label updates are required for logical model elements |
| </ul> |
| |
| |
| <h2><a name="Example"></a>EMF Library Example</h2> |
| <p>This example, available <a |
| href="libraryExample.html">here</a>, is built on a model that consists of libraries, |
| books and writers.</p> |
| |
| <h2>Change History</h2> |
| <p>Changes in version 3.2 M5</p> |
| <ul> |
| <li>Document created. |
| </li> |
| </ul> |
| </body> |
| </html> |