platform-vcm-home/docs/online/vcm_story2.0/vcm2story.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (view) (download) (as text)

1 : jlemieux 1.1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
2 :     <html>
3 :     <head>
4 :     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5 :     <meta name="GENERATOR" content="Mozilla/4.5 [en] (WinNT; I) [Netscape]">
6 :     <title>VCM Component Development Resources</title>
7 :     <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
8 :     </head>
9 :     <body text="#000000" bgcolor="#FFFFFF">
10 :     &nbsp;
11 :     <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
12 :     <tr>
13 :     <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF">VCM
14 :     2.0 Story</font></font></b></td>
15 :     </tr>
16 :    
17 :     <tr>
18 :     <td>by Kevin McGuire&nbsp;
19 :     <p>The intention of this document is to describe the overall direction
20 :     that VCM (Version Configuration Management) is taking in Eclipse, targeted
21 :     at our 2.0 release. It provides a first look into the overall design goals
22 :     and strategy we are taking, and includes a first cut of an important interface.
23 :     The goal is to initiate discussion in the open source community, and to
24 :     garner feedback from repository vendors looking to integrate with Eclipse.
25 :     <h3>
26 :     Goals</h3>
27 :     The goal of the VCM support in the Eclipse Project is to provide a mechanism
28 :     by which repository vendors can plug in adapters to integrate the full,
29 :     rich, functionality of their repository solution into the Eclipse workbench
30 :     in a first class way. The problem with many IDE integration approaches
31 :     today is that they provide only a simple and generic level of support that
32 :     we feel is an unacceptable level of integration. It does not allow repository
33 :     vendors to showcase the unique benefits of their offering and treats repository/IDE
34 :     integration as a second class afterthought. By contrast, we believe it
35 :     is critically important that the vendor be able to integrate their product's
36 :     workflow model into the overall Eclipse user experience. Our success will
37 :     be measured by the number of repositories that we can support, by the richness
38 :     of this support, and by the degree of VCM integration afforded to third
39 :     party plugins.
40 :     <h3>
41 :     Eclipse VCM 1.0</h3>
42 :     While we felt we achieved reasonable CVS support in 1.0, through that process
43 :     we understood the places where our model would not translate well to other
44 :     repository types. Thus it was a difficult but an absolutely necessary decision
45 :     to hold it back from API status in 1.0. The architecture for 2.0 is significantly
46 :     different than that in 1.0. For one, the API is smaller. Second, and most
47 :     importantly, the workflow in VCM 1.0 was specific to Eclipse and difficult
48 :     to customize for a given repository. This led to numerous fundamental problems
49 :     in compatibility between the abstract Eclipse VCM model and repositories
50 :     with rich models. What resulted was a sort of “least common denominator”
51 :     experience that was unsatisfactory to anyone who was already familiar with
52 :     the underlying repository model. Third, in many places VCM 1.0 was trying
53 :     to be “too helpful” by providing numerous built in mechanisms. While this
54 :     potentially allowed rapid integration for some repositories, in general
55 :     one ended up having to fight this helpfulness due to subtle semantic differences
56 :     between repositories. By contrast, in VCM 2.0 the repository integrator
57 :     will always be “in charge”.
58 :     <h3>
59 :     Approach</h3>
60 :     Our technical approach to this problem has two parts - a common base integration
61 :     API, together with an extension mechanism. Repository vendors implement
62 :     a simple compact base API, which provides basic functionality. The vendor then
63 :     uses the extension mechanism to provide a higher level of integration to
64 :     achieve the rich integrated experience provided by the unique benefits
65 :     of the repository/configuration management/workflow solution. This entails
66 :     writing tool plugin views, reusing common views provided by Eclipse, and
67 :     integrating vendor specific function into the appropriate extension points
68 :     in Eclipse. This approach is consistent with the overall tool integration
69 :     strategy for Eclipse, and allows each vendor to decide how rich and how
70 :     integrated an experience they will provide to their customers. It also
71 :     allows staged development, where increasingly rich plugins can be provided
72 :     over time. Further, it allows different adapter implementations to be produced
73 :     for the same repository that have different personalities... for example
74 :     one could produce a CVS adapter designed for CVS hackers, or another for
75 :     novice users. Both work with CVS, but provide different user experiences.
76 :     <h3>
77 :     Timeline</h3>
78 :     Our plan is to have the VCM 2.0 design closed off by end of year, and an
79 :     initial cut of our new CVS adapter written for VCM 2.0 in that same time
80 :     frame. We are eager to work with repository vendors in the context of the
81 :     Eclipse Project at eclipse.org in that same time frame, in order to validate
82 :     our design, and to ensure that there will be first class integrations from
83 :     the major vendors for the release of Eclipse 2.0.&nbsp;
84 :     <h3>
85 :     Current State&nbsp;</h3>
86 :     The work is still at an early stage and we expect changes to occur, in
87 :     particular in the areas of labels (a.k.a. tags). We want this API evolution
88 :     process to be driven by the requirements of repository vendors. By mid
89 :     November we hope to be releasing to dev.eclipse.org a preliminary code
90 :     drop that could be used for prototyping repository providers. We expect
91 :     that this will help clarify the story, since code speaks louder than words.&nbsp;
92 :     <h3>
93 :     Architecture</h3>
94 :     The VCM 2.0 story can be broken down into the following pieces.&nbsp;
95 :     <p><b>VCM Core</b>
96 :     <ul>
97 :     <li>
98 :     VCM 2.0 will provide a base API (ITeamProvider interface, included below)
99 :     representing the core set of VCM operations.&nbsp;</li>
100 :    
101 :     <li>
102 :     All providers must implement this interface.&nbsp;</li>
103 :    
104 :     <li>
105 :     An Eclipse project will be associated with one and only one ITeamProvider
106 :     instance.&nbsp;</li>
107 :    
108 :     <li>
109 :     There will be support for looking up an ITeamProvider instance given a
110 :     project.&nbsp;</li>
111 :     </ul>
112 :     In effect, ITeamProvider describes the abstract VCM model that other plugins
113 :     can rely on for performing repository neutral operations. For example,
114 :     a headless ISV consumer of this API could use it for writing build tools,
115 :     code generation, etc. It is up to each repository vendor to implement this
116 :     interface within the prescribed pre and post conditions, mapping the operations
117 :     onto their native repository function.&nbsp;
118 :     <p><b>VCM UI</b>&nbsp;
119 :     <ul>
120 :     <li>
121 :     There will be a mechanism by which a provider can offer up a Team menu
122 :     that other plugins can include in their views. There will be a standard
123 :     menu which a provider may choose to use wholly, supplement with additional
124 :     operations, or replace entirely.&nbsp;</li>
125 :    
126 :     <li>
127 :     Through this menu mechanism VCM acts as the intermediary between the third-party
128 :     plugin that wishes to include VCM operations in their view, and the provider
129 :     for that project who can offer up a Team menu specific to the workflows
130 :     of their repository type. This allows repository specific VCM operations
131 :     to be populated in views where the plugin writer and the repository provider
132 :     don't know about each other.&nbsp;</li>
133 :    
134 :     <li>
135 :     VCM will supply some standard views that repository providers may wish
136 :     make use of. At present this list includes the Synchronization view from
137 :     Eclipse 1.0 and the History view. In order to use these views, the repository
138 :     provider will need to conform to additional APIs. Customization or subclassing
139 :     may also be required. This offers a code reuse story for leveraging common
140 :     views so that all repository providers don't need to write each from scratch.&nbsp;</li>
141 :    
142 :     <li>
143 :     Alternatively, providers may wish to write their own custom views. This
144 :     might be required in cases where the provider is unable to conform to the
145 :     additional API, or in cases where the provider wishes to supply a view
146 :     which is either richer or works substantially different than the Eclipse
147 :     VCM supplied view. In all cases, it is the provider who is in charge.&nbsp;</li>
148 :    
149 :     <li>
150 :     Decorators can be implemented to show VCM related information of a resource,
151 :     for example in the Eclipse navigator.&nbsp;</li>
152 :    
153 :     <li>
154 :     There will be an update mechanism to inform listeners of changes to the
155 :     implied VCM properties (e.g. whether a resource is checked out or not).
156 :     This would be used, among other places, to update the resource decorators
157 :     above.&nbsp;</li>
158 :     </ul>
159 :    
160 :     <p>
161 :     The figure below shows this architectural separation for two suggested repositories, CVS and ClearClase.
162 :     </p>
163 :    
164 :     <img SRC="image001.gif">
165 :    
166 :     <p>
167 :     The dashed boxes denote those pieces that a repository integrator must implement.
168 :     For example for ClearCase, one would implement the VCM Core APIs, as
169 :     denoted by the box CC Impl, as well as certain UI components, as denoted by
170 :     CC UI. The vendor has opportunity to make repository specific calls in order to
171 :     support their UI components. However, third party tools remain agnostic with
172 :     regards to individual repository APIs and semantics.
173 :     The amount of effort required to implement the UI pieces will depend whether one
174 :     wishes to leverage the Eclipse VCM supplied UI components, or whether one wishes
175 :     to implement custom UI components that better express the workflow of that repository type.
176 :     Together, the VCM Core and UI architectures provide the pervasiveness required
177 :     for a well-integrated VCM experience, with the customization required for rich
178 :     repository integration.
179 :     </p>
180 :    
181 :     <p>
182 :     The vendor has opportunity to make repository specific calls in order to
183 :     support their UI components. However, third party tools remain agnostic
184 :     with regards to individual repository APIs and semantics. The amount of
185 :     effort required to implement the UI pieces will depend whether one wishes
186 :     to leverage the Eclipse VCM supplied UI components, or whether one wishes
187 :     to implement custom UI components that better express the workflow of that
188 :     repository type.&nbsp;
189 :     <p>Together, the VCM Core and UI architectures provide the pervasiveness
190 :     required for a well integrated VCM experience, with the customization required
191 :     for rich repository integration. Included below is the interface
192 :     ITeamProvider, the 'core' API described previously. As mentioned earlier,
193 :     this is just a first cut and will be undergoing change. Other APIs supporting
194 :     associating a provider with a project, looking up a provider for a project,
195 :     Synchronization view, History view, and decorators will be coming.
196 :     </p>
197 :     <p>For a sneak preview of the provider API see <a href="ITeamProvider_sample.html">ITeamProvider</a><!-- END OF FILE --></td>
198 :     </tr>
199 :     </table>
200 :    
201 :     </body>
202 :     </html>