platform-cvs/r2.0/vcm_story2.0/vcm2story.html - www.eclipse.org/eclipse - Git at Google

 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    <meta name="GENERATOR" content="Mozilla/4.5 [en] (WinNT; I) [Netscape]">
    <title>VCM Component Development Resources</title>
 <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
 </head>
 <body text="#000000" bgcolor="#FFFFFF">
 <p>Back to <a href="../../archivedReleases.php">Archived Releases</a></p>
 &nbsp;
 <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
 <tr>
 <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF">VCM
 2.0 Story</font></font></b></td>
 </tr>

 <tr>
 <td>by Kevin McGuire&nbsp;
 <p>The intention of this document is to describe the overall direction
 that VCM (Version Configuration Management) is taking in Eclipse, targeted
 at our 2.0 release. It provides a first look into the overall design goals
 and strategy we are taking, and includes a first cut of an important interface.
 The goal is to initiate discussion in the open source community, and to
 garner feedback from repository vendors looking to integrate with Eclipse.
 <h3>
 Goals</h3>
 The goal of the VCM support in the Eclipse Project is to provide a mechanism
 by which repository vendors can plug in adapters to integrate the full,
 rich, functionality of their repository solution into the Eclipse workbench
 in a first class way. The problem with many IDE integration approaches
 today is that they provide only a simple and generic level of support that
 we feel is an unacceptable level of integration. It does not allow repository
 vendors to showcase the unique benefits of their offering and treats repository/IDE
 integration as a second class afterthought. By contrast, we believe it
 is critically important that the vendor be able to integrate their product's
 workflow model into the overall Eclipse user experience. Our success will
 be measured by the number of repositories that we can support, by the richness
 of this support, and by the degree of VCM integration afforded to third
 party plugins.
 <h3>
 Eclipse VCM 1.0</h3>
 While we felt we achieved reasonable CVS support in 1.0, through that process
 we understood the places where our model would not translate well to other
 repository types. Thus it was a difficult but an absolutely necessary decision
 to hold it back from API status in 1.0. The architecture for 2.0 is significantly
 different than that in 1.0. For one, the API is smaller. Second, and most
 importantly, the workflow in VCM 1.0 was specific to Eclipse and difficult
 to customize for a given repository. This led to numerous fundamental problems
 in compatibility between the abstract Eclipse VCM model and repositories
 with rich models. What resulted was a sort of least common denominator
 experience that was unsatisfactory to anyone who was already familiar with
 the underlying repository model. Third, in many places VCM 1.0 was trying
 to be too helpful by providing numerous built in mechanisms. While this
 potentially allowed rapid integration for some repositories, in general
 one ended up having to fight this helpfulness due to subtle semantic differences
 between repositories. By contrast, in VCM 2.0 the repository integrator
 will always be in charge.
 <h3>
 Approach</h3>
 Our technical approach to this problem has two parts - a common base integration
 API, together with an extension mechanism. Repository vendors implement
 a simple compact base API, which provides basic functionality. The vendor then
 uses the extension mechanism to provide a higher level of integration to
 achieve the rich integrated experience provided by the unique benefits
 of the repository/configuration management/workflow solution. This entails
 writing tool plugin views, reusing common views provided by Eclipse, and
 integrating vendor specific function into the appropriate extension points
 in Eclipse. This approach is consistent with the overall tool integration
 strategy for Eclipse, and allows each vendor to decide how rich and how
 integrated an experience they will provide to their customers. It also
 allows staged development, where increasingly rich plugins can be provided
 over time. Further, it allows different adapter implementations to be produced
 for the same repository that have different personalities... for example
 one could produce a CVS adapter designed for CVS hackers, or another for
 novice users. Both work with CVS, but provide different user experiences.
 <h3>
 Timeline</h3>
 Our plan is to have the VCM 2.0 design closed off by end of year, and an
 initial cut of our new CVS adapter written for VCM 2.0 in that same time
 frame. We are eager to work with repository vendors in the context of the
 Eclipse Project at eclipse.org in that same time frame, in order to validate
 our design, and to ensure that there will be first class integrations from
 the major vendors for the release of Eclipse 2.0.&nbsp;
 <h3>
 Current State&nbsp;</h3>
 The work is still at an early stage and we expect changes to occur, in
 particular in the areas of labels (a.k.a. tags). We want this API evolution
 process to be driven by the requirements of repository vendors. By mid
 November we hope to be releasing to dev.eclipse.org a preliminary code
 drop that could be used for prototyping repository providers. We expect
 that this will help clarify the story, since code speaks louder than words.&nbsp;
 <h3>
 Architecture</h3>
 The VCM 2.0 story can be broken down into the following pieces.&nbsp;
 <p><b>VCM Core</b>
 <ul>
 <li>
 VCM 2.0 will provide a base API (ITeamProvider interface, included below)
 representing the core set of VCM operations.&nbsp;</li>

 <li>
 All providers must implement this interface.&nbsp;</li>

 <li>
 An Eclipse project will be associated with one and only one ITeamProvider
 instance.&nbsp;</li>

 <li>
 There will be support for looking up an ITeamProvider instance given a
 project.&nbsp;</li>
 </ul>
 In effect, ITeamProvider describes the abstract VCM model that other plugins
 can rely on for performing repository neutral operations. For example,
 a headless ISV consumer of this API could use it for writing build tools,
 code generation, etc. It is up to each repository vendor to implement this
 interface within the prescribed pre and post conditions, mapping the operations
 onto their native repository function.&nbsp;
 <p><b>VCM UI</b>&nbsp;
 <ul>
 <li>
 There will be a mechanism by which a provider can offer up a Team menu
 that other plugins can include in their views. There will be a standard
 menu which a provider may choose to use wholly, supplement with additional
 operations, or replace entirely.&nbsp;</li>

 <li>
 Through this menu mechanism VCM acts as the intermediary between the third-party
 plugin that wishes to include VCM operations in their view, and the provider
 for that project who can offer up a Team menu specific to the workflows
 of their repository type. This allows repository specific VCM operations
 to be populated in views where the plugin writer and the repository provider
 don't know about each other.&nbsp;</li>

 <li>
 VCM will supply some standard views that repository providers may wish
 make use of. At present this list includes the Synchronization view from
 Eclipse 1.0 and the History view. In order to use these views, the repository
 provider will need to conform to additional APIs. Customization or subclassing
 may also be required. This offers a code reuse story for leveraging common
 views so that all repository providers don't need to write each from scratch.&nbsp;</li>

 <li>
 Alternatively, providers may wish to write their own custom views. This
 might be required in cases where the provider is unable to conform to the
 additional API, or in cases where the provider wishes to supply a view
 which is either richer or works substantially different than the Eclipse
 VCM supplied view. In all cases, it is the provider who is in charge.&nbsp;</li>

 <li>
 Decorators can be implemented to show VCM related information of a resource,
 for example in the Eclipse navigator.&nbsp;</li>

 <li>
 There will be an update mechanism to inform listeners of changes to the
 implied VCM properties (e.g. whether a resource is checked out or not).
 This would be used, among other places, to update the resource decorators
 above.&nbsp;</li>
 </ul>

 <p>
 The figure below shows this architectural separation for two suggested repositories, CVS and ClearClase.
 </p>

 <img SRC="image001.gif">

 <p>
 The dashed boxes denote those pieces that a repository integrator must implement.
 For example for ClearCase, one would implement the VCM Core APIs, as
 denoted by the box CC Impl, as well as certain UI components, as denoted by
 CC UI. The vendor has opportunity to make repository specific calls in order to
 support their UI components. However, third party tools remain agnostic with
 regards to individual repository APIs and semantics.
 The amount of effort required to implement the UI pieces will depend whether one
 wishes to leverage the Eclipse VCM supplied UI components, or whether one wishes
 to implement custom UI components that better express the workflow of that repository type.
 Together, the VCM Core and UI architectures provide the pervasiveness required
 for a well-integrated VCM experience, with the customization required for rich
 repository integration.
 </p>

 <p>
 The vendor has opportunity to make repository specific calls in order to
 support their UI components. However, third party tools remain agnostic
 with regards to individual repository APIs and semantics. The amount of
 effort required to implement the UI pieces will depend whether one wishes
 to leverage the Eclipse VCM supplied UI components, or whether one wishes
 to implement custom UI components that better express the workflow of that
 repository type.&nbsp;
 <p>Together, the VCM Core and UI architectures provide the pervasiveness
 required for a well integrated VCM experience, with the customization required
 for rich repository integration. Included below is the interface
 ITeamProvider, the 'core' API described previously. As mentioned earlier,
 this is just a first cut and will be undergoing change. Other APIs supporting
 associating a provider with a project, looking up a provider for a project,
 Synchronization view, History view, and decorators will be coming.
 </p>
 <p>For a sneak preview of the provider API see <a href="ITeamProvider_sample.html">ITeamProvider</a><!-- END OF FILE --></td>
 </tr>
 </table>

 </body>
 </html>
	<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
	<html>
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	<meta name="GENERATOR" content="Mozilla/4.5 [en] (WinNT; I) [Netscape]">
	<title>VCM Component Development Resources</title>
	<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
	</head>
	<body text="#000000" bgcolor="#FFFFFF">
	<p>Back to <a href="../../archivedReleases.php">Archived Releases</a></p>

	<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
	<tr>
	<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF">VCM
	2.0 Story</font></font></b></td>
	</tr>

	<tr>
	<td>by Kevin McGuire
	<p>The intention of this document is to describe the overall direction
	that VCM (Version Configuration Management) is taking in Eclipse, targeted
	at our 2.0 release. It provides a first look into the overall design goals
	and strategy we are taking, and includes a first cut of an important interface.
	The goal is to initiate discussion in the open source community, and to
	garner feedback from repository vendors looking to integrate with Eclipse.
	<h3>
	Goals</h3>
	The goal of the VCM support in the Eclipse Project is to provide a mechanism
	by which repository vendors can plug in adapters to integrate the full,
	rich, functionality of their repository solution into the Eclipse workbench
	in a first class way. The problem with many IDE integration approaches
	today is that they provide only a simple and generic level of support that
	we feel is an unacceptable level of integration. It does not allow repository
	vendors to showcase the unique benefits of their offering and treats repository/IDE
	integration as a second class afterthought. By contrast, we believe it
	is critically important that the vendor be able to integrate their product's
	workflow model into the overall Eclipse user experience. Our success will
	be measured by the number of repositories that we can support, by the richness
	of this support, and by the degree of VCM integration afforded to third
	party plugins.
	<h3>
	Eclipse VCM 1.0</h3>
	While we felt we achieved reasonable CVS support in 1.0, through that process
	we understood the places where our model would not translate well to other
	repository types. Thus it was a difficult but an absolutely necessary decision
	to hold it back from API status in 1.0. The architecture for 2.0 is significantly
	different than that in 1.0. For one, the API is smaller. Second, and most
	importantly, the workflow in VCM 1.0 was specific to Eclipse and difficult
	to customize for a given repository. This led to numerous fundamental problems
	in compatibility between the abstract Eclipse VCM model and repositories
	with rich models. What resulted was a sort of least common denominator
	experience that was unsatisfactory to anyone who was already familiar with
	the underlying repository model. Third, in many places VCM 1.0 was trying
	to be too helpful by providing numerous built in mechanisms. While this
	potentially allowed rapid integration for some repositories, in general
	one ended up having to fight this helpfulness due to subtle semantic differences
	between repositories. By contrast, in VCM 2.0 the repository integrator
	will always be in charge.
	<h3>
	Approach</h3>
	Our technical approach to this problem has two parts - a common base integration
	API, together with an extension mechanism. Repository vendors implement
	a simple compact base API, which provides basic functionality. The vendor then
	uses the extension mechanism to provide a higher level of integration to
	achieve the rich integrated experience provided by the unique benefits
	of the repository/configuration management/workflow solution. This entails
	writing tool plugin views, reusing common views provided by Eclipse, and
	integrating vendor specific function into the appropriate extension points
	in Eclipse. This approach is consistent with the overall tool integration
	strategy for Eclipse, and allows each vendor to decide how rich and how
	integrated an experience they will provide to their customers. It also
	allows staged development, where increasingly rich plugins can be provided
	over time. Further, it allows different adapter implementations to be produced
	for the same repository that have different personalities... for example
	one could produce a CVS adapter designed for CVS hackers, or another for
	novice users. Both work with CVS, but provide different user experiences.
	<h3>
	Timeline</h3>
	Our plan is to have the VCM 2.0 design closed off by end of year, and an
	initial cut of our new CVS adapter written for VCM 2.0 in that same time
	frame. We are eager to work with repository vendors in the context of the
	Eclipse Project at eclipse.org in that same time frame, in order to validate
	our design, and to ensure that there will be first class integrations from
	the major vendors for the release of Eclipse 2.0.
	<h3>
	Current State </h3>
	The work is still at an early stage and we expect changes to occur, in
	particular in the areas of labels (a.k.a. tags). We want this API evolution
	process to be driven by the requirements of repository vendors. By mid
	November we hope to be releasing to dev.eclipse.org a preliminary code
	drop that could be used for prototyping repository providers. We expect
	that this will help clarify the story, since code speaks louder than words.
	<h3>
	Architecture</h3>
	The VCM 2.0 story can be broken down into the following pieces.
	<p><b>VCM Core</b>
	<ul>
	<li>
	VCM 2.0 will provide a base API (ITeamProvider interface, included below)
	representing the core set of VCM operations. </li>

	<li>
	All providers must implement this interface. </li>

	<li>
	An Eclipse project will be associated with one and only one ITeamProvider
	instance. </li>

	<li>
	There will be support for looking up an ITeamProvider instance given a
	project. </li>
	</ul>
	In effect, ITeamProvider describes the abstract VCM model that other plugins
	can rely on for performing repository neutral operations. For example,
	a headless ISV consumer of this API could use it for writing build tools,
	code generation, etc. It is up to each repository vendor to implement this
	interface within the prescribed pre and post conditions, mapping the operations
	onto their native repository function.
	<p><b>VCM UI</b>
	<ul>
	<li>
	There will be a mechanism by which a provider can offer up a Team menu
	that other plugins can include in their views. There will be a standard
	menu which a provider may choose to use wholly, supplement with additional
	operations, or replace entirely. </li>

	<li>
	Through this menu mechanism VCM acts as the intermediary between the third-party
	plugin that wishes to include VCM operations in their view, and the provider
	for that project who can offer up a Team menu specific to the workflows
	of their repository type. This allows repository specific VCM operations
	to be populated in views where the plugin writer and the repository provider
	don't know about each other. </li>

	<li>
	VCM will supply some standard views that repository providers may wish
	make use of. At present this list includes the Synchronization view from
	Eclipse 1.0 and the History view. In order to use these views, the repository
	provider will need to conform to additional APIs. Customization or subclassing
	may also be required. This offers a code reuse story for leveraging common
	views so that all repository providers don't need to write each from scratch. </li>

	<li>
	Alternatively, providers may wish to write their own custom views. This
	might be required in cases where the provider is unable to conform to the
	additional API, or in cases where the provider wishes to supply a view
	which is either richer or works substantially different than the Eclipse
	VCM supplied view. In all cases, it is the provider who is in charge. </li>

	<li>
	Decorators can be implemented to show VCM related information of a resource,
	for example in the Eclipse navigator. </li>

	<li>
	There will be an update mechanism to inform listeners of changes to the
	implied VCM properties (e.g. whether a resource is checked out or not).
	This would be used, among other places, to update the resource decorators
	above. </li>
	</ul>

	<p>
	The figure below shows this architectural separation for two suggested repositories, CVS and ClearClase.
	</p>

	<img SRC="image001.gif">

	<p>
	The dashed boxes denote those pieces that a repository integrator must implement.
	For example for ClearCase, one would implement the VCM Core APIs, as
	denoted by the box CC Impl, as well as certain UI components, as denoted by
	CC UI. The vendor has opportunity to make repository specific calls in order to
	support their UI components. However, third party tools remain agnostic with
	regards to individual repository APIs and semantics.
	The amount of effort required to implement the UI pieces will depend whether one
	wishes to leverage the Eclipse VCM supplied UI components, or whether one wishes
	to implement custom UI components that better express the workflow of that repository type.
	Together, the VCM Core and UI architectures provide the pervasiveness required
	for a well-integrated VCM experience, with the customization required for rich
	repository integration.
	</p>

	<p>
	The vendor has opportunity to make repository specific calls in order to
	support their UI components. However, third party tools remain agnostic
	with regards to individual repository APIs and semantics. The amount of
	effort required to implement the UI pieces will depend whether one wishes
	to leverage the Eclipse VCM supplied UI components, or whether one wishes
	to implement custom UI components that better express the workflow of that
	repository type.
	<p>Together, the VCM Core and UI architectures provide the pervasiveness
	required for a well integrated VCM experience, with the customization required
	for rich repository integration. Included below is the interface
	ITeamProvider, the 'core' API described previously. As mentioned earlier,
	this is just a first cut and will be undergoing change. Other APIs supporting
	associating a provider with a project, looking up a provider for a project,
	Synchronization view, History view, and decorators will be coming.
	</p>
	<p>For a sneak preview of the provider API see <a href="ITeamProvider_sample.html">ITeamProvider</a><!-- END OF FILE --></td>
	</tr>
	</table>

	</body>
	</html>