| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <meta name="Author" content="Eclipse Project"> |
| <title>Eclipse Team Component Roadmap</title> |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| <h1>Eclipse Team Component Roadmap</h1> |
| <blockquote> |
| <p><strong>Summary</strong>:<br> |
| This document outlines the current problems with Team and CVS support in Eclipse. |
| It also suggests some important new Team features that should be considered |
| for future releases of the platform. This does not represent a commitment |
| to pursue any of the below mentioned areas. It is a draft of potential future |
| areas of focus for the Eclipse Team component.</p> |
| <p>Last Modified: April 17, 2003</p> |
| <p><strong>Table of Contents:</strong></p> |
| <p><a href="#" target="team_plugin">Team Plugin</a><br> |
| <a href="#resourceplugin">Resources Plugin</a><br> |
| <a href="#uiplugin">UI Plugin</a><br> |
| <a href="#api">Team APIs</a><br> |
| <a href="#target">Target Management</a><br> |
| <a href="#collaboration">Enhanced collaboration support</a><br> |
| <a href="#cvs">What's next for CVS</a></p> |
| </blockquote> |
| <hr> |
| <h2><a name="teamplugin">Team Plugin</a></h2> |
| <ol> |
| <li>Dispatching project based resource control extension points</li> |
| <p>The Team plugin currently extends several core extension points for resource |
| management (file modification validator, team hook, move/delete hook). This |
| is a rather piecemeal approach that still does not provide enough control |
| (e.g. copy semantics, missed deltas). These facilities should be consolidated |
| and should provide the repository provider with an increased integration with |
| the resources plugin. Some examples of existing problems:</p> |
| <ul> |
| <li>Until the Team plugin is loaded there are no hooks registered. This is |
| very problematic when you consider that the need for implementing a hook |
| is usually to provide some meta file sanity on the versioned resources. |
| And missing resource changes can result in inconsistent provider meta file |
| state.</li> |
| <li>There are missing cases where the provider needs more control over resources |
| (e.g. copy)</li> |
| <li> Are the hooks really Team specific or should they instead be available |
| to other types of plugins?</li> |
| As a case in point, PDE is currently a repository provider to gain some control |
| over binary projects. |
| </ul> |
| <p></p> |
| <li>Sync view (non-API, usability, threading, pervasive sync)</li> |
| <p>One of the most impressive features of the Team story is the excellent integration |
| with compare technology. CVS users can visually compare, merge, and integrate |
| changes within the workbench. This makes CVS very accessible to many users |
| that never would of though of using CVS via the command line. However, even |
| with the current high level of integration of the compare infrastructure there |
| is much room for improvement. Most of the proposed sync enhancements are meant |
| to improve a user's awareness of what others on their team are doing. With |
| this additional sync awareness and the suggestions mentioned in the <a href="#collaboration">Expanded |
| Collaboration Support</a> section, the Team component will enable a unique |
| and very rich collaboration infrastructure in Eclipse. The appendix contains |
| a detailed list of problems with the sync view but here is how we would like |
| to see the sync view evolve:</p> |
| <ul> |
| <li> Split the current sync view into several pieces that work together. This |
| would include a synchronize view that displays a 'live' sync view of resources |
| in the workspace. And compare editors would be opened to edit sync nodes.</li> |
| <li>There is no API for reporitory providers to re-use the sync view. This |
| inhibits other providers from benefiting from the sync support.</li> |
| <li>Provide a better representation of changes than a full tree view. Possible |
| alternatives could be to use a compact tree or table.</li> |
| <li>Additional information about sync changes should be available to understand |
| how team members are making changes that affect your work (e.g. user names, |
| code changes, comments, activities).</li> |
| <li>There should be different places for showing sync information (tasks in |
| editors, sync view, decorations).</li> |
| <li> The view that shows sync state for changes should be live and show outgoing |
| changes without having to synchronize with the server.</li> |
| <li>Calculate the incoming changes in the background </li> |
| </ul> |
| <p></p> |
| <li>It would be useful for the Team to help the community start a repository |
| provider plugin for Subversion (e.g. the replacement for CVS) and ensure that |
| the ClearCase plugin is as well integrated as CVS.</li> |
| <p></p> |
| <li>Logical to physical mapping has always been an outstanding problem in Eclipse. |
| Here are two examples: |
| <p></p> |
| <ul> |
| <li>In the Java packages explorer if you select a package then perform Team |
| > Commit.. the action will perform the operation on all child resources |
| of the package although visually the package really only contains immediate |
| children. |
| <li>Outgoing dirty indicators contributed by the CVS plugin decorate logical |
| views because the decorator is based on the physical resource model. |
| </ul> |
| </li> |
| <p></p> |
| <li>Better understanding of end to end scenarios as they are and how they should |
| be (roles, editor integration, compare/sync, update, etc). The scenarios to |
| consider are things like: |
| <p></p> |
| <ul> |
| <li>How are projects shared (differs by repository provider)? Do we still |
| need a Team > Share... menu item or are providers using their own mechanisms |
| instead? </li> |
| <li>How are operations performed (main menu, context menu, key-strokes).</li> |
| <li>Where are operations performed (view, editor, perspective, roll)</li> |
| <li>Resource synchronization/merging</li> |
| <li>comparing</li> |
| <li>patching (do others use Team>Apply Patch?)</li> |
| <li>sharing workspace setup (project sets, properties, preferences)</li> |
| <li>sharing project setup (properties, linked resources)</li> |
| <li>transactions (validateSave/Edit)</li> |
| <li>file type management</li> |
| <li>ignored resources</li> |
| </ul> |
| </li> |
| </ol> |
| <hr> |
| <h2>Resources plugin<a name="resourceplugin"></a></h2> |
| <ol> |
| <li>Resource history management in the resources plugin should be reviewed. |
| Currently callers of IResource API decide on the history configuration of |
| a resource and there is no way to impose a workbench wide policy - IResource.setContents(keepHistory). |
| This is a very fragile mechanism because random plugins can delete history |
| and users cannot configure their own versioning based rules. For example, |
| local history could be purged on commit.</li> |
| <br> |
| <br> |
| <li>Permission support is missing from core which makes it impossible for plugins |
| to synchronize the remote permissions with the local. This is really a pain |
| when users put scripts/executables into a remote location as the subsequent |
| retrieval</li> |
| will not have the proper permissions.<br> |
| <br> |
| <li>Workspace locking granularity and deadlocks when plugins use their own locking |
| mechanism. We have had many problems with the decorators with deadlock.</li> |
| <br> |
| <br> |
| <li>Copy semantics need to be integrated into team hooks. For example, most |
| team providers have work to do on copy (e.g. handle meta files...) and are |
| currently not given the chance to do so.</li> |
| <br> |
| <br> |
| <li>Should phantoms be considered as generalized synchronization mechanism and |
| shown by viewers? Or are they a mechanism for synchronization providers. There |
| is a good discussion about the role of phantoms in the platform. Are they |
| a mechanism that plugins can use to store sync info or should they be the |
| imposed method of storing sync info? Having phantoms as a first class synchronization |
| concept in the platform would allow sync information to be available in any |
| resource based view (e.g. the navigator) via phantoms. But realistically it |
| is naive to think that team provider plugins must use phantoms to track synchronization |
| information. </li> |
| <br> |
| <br> |
| <li>Team-private resources marking is problematic because there are cases (e.g. |
| the plugin isn't loaded yet) were this story breaks down. Plugins wanting |
| to mark resources as team-private must be allowed to do so without having |
| to worry about plugin loading issues.</li> |
| <br> |
| <br> |
| <li>Aggressive builds - empty deltas or deltas with non-build specific information |
| like sync changes.</li> |
| <br> |
| <br> |
| <li>Integration of local history and provider history (see <a href="#collaboration">Expanded |
| Collaboration Support</a>)</li> |
| <br> |
| <br> |
| <li>The use of linked resources can break validateSave/Edit and other Core hooks. |
| Consider the scenario involving linking resources from a shared project into |
| a non-shared project. Operations performed on the non-shared project may involve |
| resources that are linked. Non of the Core hooks will be invoked for these |
| resources even though they are under version control in another project.</li> |
| </ol> |
| <hr> |
| <h2>UI plugin<a name="uiplugin"></a></h2> |
| <ol> |
| <li>UI Decorator support currently has several problems. The CVS decorator's |
| performance has degregated from 2.0 to 2.1 and there still seems like there |
| are some important changes required to make the decoration mechanism scalable.</li> |
| <br> |
| <br> |
| <li>Dynamic views or view re-use. Team would like to provide a sync view that |
| can be re-used by several providers simultaneously activated in the workbench. |
| For example, if you had CVS and FTP enabled for a project you would have two |
| sync views.</li> |
| <br> |
| <br> |
| <li>Keyboard bindings for object contributions. Repository provides add their |
| menu items to other views using popup menu object contibutions in plugin.xml. |
| There actions are currently not key-binadable which requires providers to |
| additionaly provide global actions for any key-bindable operations.<br> |
| <br> |
| </li> |
| <li>Access to Team operations from within an editor. Currently the user must perform |
| team operations on a resource that appears in a view. It would simplify the user's workflow |
| if there menu operations were also available in an editor. |
| <br> |
| <br> |
| </li> |
| <li>Password clearing support from the UI. The core password facility is used |
| by several plugins but there is no UI support for clearing the passwords known |
| to the workspace. (Bug 8947)</li> |
| <br> |
| <br> |
| <li>Filter rules applied to object contributions. When an action is run from |
| a view that is currently being filtered the action can only assume that all |
| resources are being shown. For example, if a filter is applied to the navigator |
| view and a users performs a commit on a folder the commit will apply to all |
| children of the folder and not only the visible items.</li> |
| </ol> |
| <hr> |
| <h2>Team APIs<a name="teamapi"></a></h2> |
| <p>There is a long history of VCM APIs in Eclipse :) In the early days of Eclipse |
| we thought that an API was the foundation on which the Eclipse VCM support should |
| be built and spent quite a while trying to realize this. That was Eclipse 1.0. |
| </p> |
| <p>As a result of the 1.0 API, several repositories, including CVS, were forced |
| to bend and contort to implement the API. And what ended up happening was that |
| each repository wasn't able to fully expose their functionality within Eclipse. |
| We had an API, but the repository integration within Eclipse was weak.</p> |
| <p>As part of the 2.0 release we shifted our priority from an API and concentrated |
| instead on providing repositories the mechanisms for rich integration into the |
| workbench (file system hooks, decoration, menu contributions, project association). |
| Our goal was to ensure that any repository provider could integrate easily and |
| show-off their cool features within the workbench. Based on the number of providers |
| that have integrated with Eclipse in such a short period and the small number |
| of questions we feel that we have succeeded. </p> |
| <p>Beyond 2.1 we want to improve and fix the problems with the existing integration |
| mechanisms. In addition we would like to understand the community's need for |
| VCM APIs. So far we aren't sure if people want an API for CVS (e.g. repository |
| specific) or a more general API for VCM. There are obvious use cases that support |
| the need of some flavour of APIs: (a) release engineering needs access to the |
| repository, (b) 3rd parties could extend a repository providers integration |
| by building new cool tools - see Hipikat, bug 24882, Jazz project, and many |
| others, (c) headless control of the repository..</p> |
| <p>Our position on a general API for VCM is that we don't want to be the ones |
| inventing or imposing an API because we know from experience that we shouldn't |
| be in that business. It's up to the repository vendors to prove to us that there |
| is buy in for such an API. Instead, if there was a reference implementation |
| and an Eclipse plugin showing that (a) the API can be implemented, and (b) there |
| is interest from other repository vendors to implement the API, we could then |
| start investigating how to integrate the API into the Eclipse VCM deliverable.</p> |
| <p>The motivation for APIs is no longer based entirely on our desire to build |
| *the* generic Team UI but instead to complement the current Team support (very |
| rich integration story for providers) with an API story that can solve the above |
| issues. We have learned our lesson and know that an API should never be the |
| only option for providers to integrate into Eclipse, but that doesn't mean that |
| it can't become *another* option.</p> |
| <p>The interest in JSR-147 is that it is a repository vendor approved API that |
| is actually close to what we would need for generic access. See http://www.jcp.org/en/jsr/detail?id=147 |
| for more details.</p> |
| <hr> |
| <h2>Target Management/Deployment<a name="target"></a></h2> |
| <p>The Eclipse download page contains a link to a prototype for target management |
| support. It includes ftp and dav as two supported targets. Given the new J2EE |
| requirements we should investigate if there is a need for a real deployment |
| story in Eclipse. </p> |
| <p>If there any push for making this prototype real we would have to:</p> |
| <ul> |
| <li>flush out the relationship between target providers and versioning providers |
| (currently they are completely separate and target is implemented as a copy |
| of the repository provider code).</li> |
| <li>by getting rid of the duplicated target provider mapping code </li> |
| <li>make the ftp and dav plugins product quality.</li> |
| </ul> |
| <hr> |
| <h2>Expanded collaboration support<a name="collaboration"></a></h2> |
| <p>During the 2.0 timeframe the VCM component was renamed to Team to reflect the |
| components problem domain as being more than versioning and configuration management. |
| Unfortunately the only other avenue explored in the 2.0 release was Target Management. |
| In the future the Team component should be the catalyst for platform changes |
| that enable deep collaboration support in Eclipse. There are a number of existing |
| projects that are focused on collaboration support in Eclipse and it isn't our |
| intention of adding all the tools but instead ensuring that the support is available |
| in Eclipse for building the tools. We have compiled the following wish list |
| for expanded collaboration support.</p> |
| <ol> |
| <li> <strong>Resource variant awareness</strong> |
| <p>We should investigate adding the metaphor that every resource has the potential |
| for "variants" to exist. When a team works on a problem together |
| the resources they create will always change over time: you can change a |
| file and save it, add to a repository and someone else can change it, add |
| to a web server via webdav and have someone else change it. We would like |
| to focus increasing the users awareness about the variants and break down |
| the barriers to having every tool that creates variants (local history, |
| cvs, ftp, webdav) use a set of common mechanisms.</p> |
| </li> |
| <li><strong>Editor change awareness and viewing support</strong> |
| <p>To support resource variant awareness editors could be enhancements to |
| support viewing the variants. This would improve on the current problem |
| of having dedicated compare text viewers for looking at changes but not |
| being able to have full editor support in the viewers. Some options for |
| editor support could include:</p> |
| <ul> |
| <li>editor support for comparison via split pane (vertical/horizontal) or |
| text markup (e.g. Word revision markings)</li> |
| <li>use of tasks to mark changes that other team members are making to an |
| opened file</li> |
| <li>use of tasks to mark annotations (comments or other) that other team |
| members are making to an opened file</li> |
| </ul> |
| </li> |
| <br> |
| <li><strong>Combined history support</strong> |
| <p>It should be possible to build views that show the combined list of variants |
| for a resource. The input to the list can be one of many sources of variants. |
| For example, the local history could be combined with the CVS resource history.</p> |
| </li> |
| <li><strong>Support for both content and naming variants</strong></li> |
| <p>Resources can either have their content changed or naming. The support for |
| tracking these changes could be investigated.</li> </p> |
| <li><strong>API to support integration of collaboration tools into Eclipse</strong> |
| <p>Most collaboration tools (e.g. Jazz, Hipikat) built on Eclipse will require |
| access to the variants that are stored in some team location. Currently |
| the collaboration tools rely on the CVS plugin to fetch revision history, |
| previous file contents, user names for resource variants. This makes the |
| collaboration tools incompatible with other resource sharing tools (e.g. |
| ClearCase, ftp, webdav). Having a suitable API for Team would help solve |
| this current problem and help expand collaboration support in Eclipse.</p> |
| </li> |
| </ol> |
| <hr> |
| <h2>What's next for CVS<a name="cvs"></a></h2> |
| <ol> |
| <li>The CVS plugin should not be part of the platform SDK. There should be a |
| CVS component separate from VCM (Team). This would allow CVS to have a top |
| level menu and in general allow other providers to be alone in the workbench.</li> |
| <li>CVS Repositories View and Tag Management</li> |
| <li>Infrastructure to prevent regressions in functionality and performance</li> |
| <li>Implementation of new Sync View APIs</li> |
| <li>Implementation of (if any) generic API</li> |
| <li>Improvement of CVS workflows for Eclipse developers (e.g. integration with |
| Bugzilla and search capabilities)</li> |
| <li>Working with multiple respositories</li> |
| <li>Improved branching/merging support</li> |
| <li>Improved patch support (creating patches from sync view, applying patches |
| via sync view).</li> |
| </ol> |
| <hr> |
| <h1>Appendix<a name="appendix"></a></h1> |
| <p>This is a summarized list of issues with the current sync view and associated |
| bug reports:</p> |
| <p><strong>Structure compare part has many usability problems</strong></p> |
| <ol> |
| <li>The problem is that the things you are interested in (the leaves of the |
| tree) are continually scrolled out of view and separated by a great distance |
| when the tree is expanded, making it hard to see at a glance what has changed. |
| It also makes multi-selection operations very painful, for example comitting |
| a set of related files that should have the same comment. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=12453">12453</a>, |
| <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=16249">16249</a>) </li> |
| <li>There are several also several expansion/selection usability problems with |
| the part. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35187">35187</a>, |
| <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33041">33041</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=4931">4931</a>, |
| <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=5431">5431</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20847">20847</a>, |
| <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=27237">27237</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=16249">16249</a>)</li> |
| <li>Synchronize view modes (filtering) and conflict workflows must be improved |
| (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=10556">10556</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=9451">9451</a>, |
| <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=139">139</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19712">19712</a>)</li> |
| </ol> |
| <p><strong>Finding the outgoing changes requires a long running operation</strong></p> |
| <blockquote> |
| <p>To commit outgoing changes you have to hit the server. This is really painful |
| since the list of outgoing changes can be determined without considering the |
| remote files.</p> |
| </blockquote> |
| <p><strong>Synchronization view doesn't fit with workbench view/editor paradigm</strong></p> |
| <blockquote> |
| <p>The sync view is essentially an editor and a view combined. Unfortunatly |
| they don't quite work as any other view/editor combination in the workbench.What |
| would happen if we split the structure compare away and made that a view on |
| the sync states of all resources in the workbench and then allowed opening |
| a compare editor (basically the bottom portion) when merging or viewing changes |
| was required?</p> |
| </blockquote> |
| <p><strong>Background fetching of remote state</strong></p> |
| <blockquote> |
| <p>Currently when a project is synchronized the complete remote tree is fetched |
| and a progress dialog is shown. The user can't perform any other operation |
| while the remote tree is fetched. There is no reason why this couldn't be |
| fetched in the backgroup without blocking the UI and would allow an awareness |
| of what other people in the team are working on and help reduce the time needed |
| to find out what others are doing.</p> |
| </blockquote> |
| <p><strong>Java text merge editor isn't real</strong> </p> |
| <blockquote>Would like to use <em>real</em> editors for merging instead of the |
| <em>neutered</em> ones currently used. For example, the java editor shown in |
| the sync view looks real (e.g. syntax coloring) but is a scaled down java editor. |
| This causes integration and context problems because it is very useful to try |
| and write code in these editors without resorting to opening the file with the |
| real java editor. Then going back to the sync view only to find that the file |
| hasn't refreshed.</blockquote> |
| <p><strong>Compare editors (merge/compare) versus sync view</strong></p> |
| <blockquote> |
| <p>The terminology and look and feel of the merge editor and sync view is different. |
| Basically a merge is the same as synchronizing except for the fact that you |
| can't commit changes. Merging is already a tricky operation and having a conflicting |
| usage model between the sync and merge makes it even harder. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35577">35577</a>)</p> |
| </blockquote> |
| <p><strong>Comparison criteria is not well integrated into compare</strong> </p> |
| <blockquote> |
| <p>The comparison criteria that is used to calculate the sync state is hidden |
| from the user and it isn't obvious for them when the criteria should be changed |
| and what advantage it will have. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=24887">24887</a>, |
| <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=21612">21612</a>, <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=28143">28143</a>)</p> |
| </blockquote> |
| <p><strong>[CVS] Synchronizing against an existing project is not well supported</strong> |
| </p> |
| <blockquote> |
| <p>This is somewhat of a CVS problem but relates to the more general issue of |
| when to change the comparison criteria. (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=21612">21612)</a></p> |
| </blockquote> |
