<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 &gt; 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&gt;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 &quot;variants&quot; 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>