[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stellation-res] Initial Eclipse client APIs posted for discussion
|
Hi Jonathan --
First, let me apologize for not responding sooner. I've been waiting
for time to write a more detailed reply than "thanks for the input,
I'll get back to you soon".
So - thanks for the input!
I really appreciate the thought that went into your detailed "Near Term
Stellation Architecture" doc. I certainly agree that an overall architecture
doc is sorely needed, and should be one of the outputs of the current
Eclipse client API work.
In the current API design, the breakdown is roughly as follows:
** Scm "Client Core":
IScmProject [ has IScmArtifactMap and BranchImage]
IScmFactory
IScmAccessPoint
The Client Core provides the fundamental conduit between a
local Stellation-managed Eclipse project and the associated
Stellation repository.
Factory - builds ScmProjects and ScmAccessPoints
AccessPoints - required by ScmProject; also useful
for getting information from a repository, or (perhaps)
remote repo administration.
** Mapping between Eclipse and Stellation resources
Eclipse IPaths are mapped to Stellation ArtifactIDs by the
IScmArtifactMap for a given IScmProject.
Eclipse IResources are mapped to IPaths by the ScmProject.
Note that the IScmArtifactMap does *not* alter the local
Stellation project image; local project image manipulation
is actually performed by IScmProject.
Jonathan's diagram implies that the Eclipse-to-Stellation
mapping is performed *outside* of the Client Core (which
Jonathan called "Stellation Client Manager"), within
a "Stellation Repository Manager" entity. The actual
resource-level mapping is currently performed *inside*
the Client Core. So are basic team management
facilities (checkin, checkout, fork, move, rename, delete...).
** Additional Stellation Client Components.
The complete "Stellation Client for Eclipse" will include
a number of components (this is not a complete list):
* Resource listeners for updating the local Stellation project
image when Eclipse project resources change (this is already
in the current plug-in).
* Support for using the Eclipse (CVS) visual merge editor
with Stellation (not yet implemented).
* Resource Decorator support (not yet implemented)
* Project properties pages, Workspace Preferences pages
(some are present in current plug-in).
These components are clearly not part of the 'Client Core'.
I also expect that, over time, various analytical and other
tools will be built on top of the Client Core.
For fine-grained support, we'll need components for Java editor
integration, Outline view integration, Query specification and
fragment property inspection etc. etc. Further details are
given in the "Fine-Grained Roadmap" doc up on our website.
** Stellation Workspace and Command Line
The 'Workspace' notion stems from the original command-line
client. The current Eclipse client API doesn't use it, partly
because IScmProject seems sufficient, and partly to avoid
confusion with the Eclipse Workspace.
I have just added support to IScmProject for locally-persistent
properties; these are persistent across multiple Eclipse sessions on
a given workstation, but are not stored in a Stellation repository
with regular project data/metadata. The immediate motivation
was for storing the "new Artifact ID counter" value (stored by
Svc in workspace.xml). Between the project-related metadata
already stored by Eclipse and the IScmProject locally-persistent
properties, I'm hoping that a distinct 'ScmWorkspace' class
won't be needed.
Your notion of a "Stellation Workspace" seems very close
to the current BranchImage class (stellation.repos.BranchImage).
A BranchImage represents the current contents of a Stellation
project, in terms of artifacts, with no reference to file-system-
specific constructs of any kind. While the current Svc
Project class is derived from BranchImage, IScmProject
(so far) contains an instance of BranchImage:
a) To me, the relationship between a project and a particular
branch image is "has-a", not "is-a".
b) The ScmProject gets down'n'dirty with the Eclipse model
of resources and the file system. The BranchImage is completely
divorced from such messiness. I'd like to keep it that way.
You've suggested a Stellation Command Line Utility which uses
IScmProject. This is certainly possible (the Eclipse framework
supports non-GUI command-line applications). However, such
a client would need to use org.eclipse.core mechanisms
for file system manipulation (IPath, IResource, etc)
rather than standard Java File and I/O classes used by the current
Svc client, since IScmProject is (currently at least) hardwired to
use the Eclipse resource model.
It may be possible to factor out "essential" Stellation client functionality
from IScmProject, into a form that would be shareable between an Eclipse
client and an Svc-like client, but that's outside the scope of my current
work. It could happen in the next pass (when we add full fine-grained
support to the Client Core), but frankly I'd rather see development of
a fully Eclipse-based command line client. (In fact, I'd *love* to see
that happen, and would be happy to refactor "Core Client" code
if necessary to better support shared use by Eclipse and command-line
clients.)
** "Persistent Stellation Workspace"
I'd rather not go that way, for several reasons. The primary one
is that most of your proposed functionality could be accomplished
by using a local Stellation repository, once we support replication
between Stellation repositories (definitely one of our goals).
Why build and maintain two complex entities to do what's basically
the same job?
The Svc workspace already has a notion of "workspace state" which is
locally persistent, motivated by many of the reasons you cite.
We've since concluded this is not such a great idea:
* the local "workspace state archive" is basically a "lightweight repository"
- but not exactly.
* the two entities do *not* have identical behavior, leading to confusion
and additional code maintenance.
* there is a significant performance hit related to saving the *entire* project
workspace state to a local zip archive before most Stellation operations.
A local repository, hosted on a local database, would likely do a better
job. Also - the Eclipse "local resource history" mechanism fills some of
the same needs; it should be possible to leverage it even more as the
Stellation Client develops.
Switching between "local" and shared repository" mode will hopefully
be as simple as rebinding an ScmAccessPoint to a different repository.
If you want to build an Envy-like workspace implementation on
top of Stellation for other reasons, please post more details about
those reasons. I suspect (hope) that the upcoming fine-grained
support will go a long way towards addressing "workspace Envy".
Thanks again for the input - looking forward to your reply.
Best regards,
Jim
At 11:06 PM 10/6/2002, Jonathan Gossage wrote:
<snip>
Your documents prompted me to make a start at a document that I feel is
missing from Stellation, namely an overall architecture document that
describes the various Stellation components and how they fit together. So I
have made a first attempt at putting such a document together, and in the
process I have identified a possible architecture for Stellation that is
sufficiently decoupled so as to be easy to maintain in the future as
requirements change.
Even if you find the specific suggestions that I have made to be
unacceptable, I think that the idea of the document is important and that
the team should jointly flesh out the content based on whatever overall
architecture is agreed on.
The document is in HTML format, but I have not had a chance to verify it
with a variety of browsers and have not had any chance to look at it under
Linux. However I have verified that it is displayable using Mozilla 1.1.
Regards
Jonathan
Personal Email
jgossage@xxxxxxxx
Business Email
jonathan@xxxxxxxxxxxxxx
--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
