RE: [stellation-res] Code Audit for Workspace package

["Rodolfo M. Raya" <rmraya@xxxxxxxxxxxxxxx>]

On Tue, 2002-09-03 at 15:42, Jim Wright - IBM Research wrote:

Hi Jim,

    I'm glad you're interested in the core scm API, and making it work with SWT.

Thanks.

    The command mechanism I'm working on is different from the current Svc
    command-line interface.  My in-progress mechanism fits between stock Eclipse
    command handlers (e.g. classes implementing IAction, IObjectActionDelegate,
    IWorkbenchWindowPulldownDelegate, etc.) and model-level Stellation
    functionality (e.g. stellation.scm.model.ScmFacade.Checkin).
    
    There is a separate chunk of work concerned with updating the current Eclipse
    GUI code to talk directly to Projects, BranchImages, Artifacts, Agents,
    Inputs, and Outputs.  Currently, ScmFacade, ScmEnvirons, InfoLister and
    related classes talk fairly directly to core workspace code (the same
    classes used by the Svc command-line driver).   This worked okay (sort of)
    as a quick'n'dirty approach,  but there's way too much command-line-specific
    gunk in there.  Furthermore, to get fine-grained support working, the
    Eclipse UI code *has* to talk directly to Projects, BranchImages, Artifacts
    and the like.
    
I wish to talk directly to projects, branches or individual artifacts.
The best scenario would be to depend only on svc.jar and keep Eclipse
far away. 

    The picture I'm thinking of looks something like this:
    
    (a) Stock Eclipse UI command handlers (IAction,
               IActionDelegate, etc.)
           \
          (b) stellation.scm.ui.action 'ScmCommand' objects
                \
               (c) stellation.scm.model 'Fine-grained-image' APIs and wrapper
                    classes
                     \
                     (d) stellation.repos core functionality and
                          stellation.workspace.Project
                             /
                           /
    (e) Svc command-line driver and helper classes
    
    
(d) and (e) are the levels I want to interact at.

     [...] 


    The command-line client (e) will continue to use stellation.repos code (d).
    In fact, since stellation.workspace essentially *is* the command-line
    client, we may want to move Project into stellation.repos, or otherwise
    refactor so that the Eclipse Stellation client avoids any direct use of
    stellation.workspace code.  

IMO, _any_ client should avoid any direct use of workspace code. 

    The dividing line between (c) and (d)
    is pretty fuzzy at present; (c) may end up containing only
    Eclipse-specific functionality code (e.g. the current resource change tracking
    mechanism), with all Stellation-specific functionality in one of the 
    stellation.repos packages, and invoked directly by the Eclipse client code as needed.
    
Please keep repository functionality separated from Eclipse-specific
functionality.

    The end goal is to have a single implementation of the core functionality which
    is equally usable by both GUI clients and command-line clients.  This should
    also support a standalone SWT-based client reasonably well.  

Imagine a future like the current status of CVS. There are a lot of
clients that can interact with a CVS server and we could expect a lot of
clients for Stellation too. 


    (Note, however, that a standalone client won't be able to use Eclipse 
    resource management.Thus, you'll either have to use the 
    stellation.workspace code for local file system
    management, or roll your own code.  

    It might be easier to use a really stripped-down
    Eclipse app (e.g. eclipse.core.XXX, SWT, but not much else), as Mark has 
    discussed earlier as a possible way of reimplementing the Svc 
    command-line client.)

My goal is to create a small & fast tool, completely independent from
Eclipse, that can be distributed as a couple of jars plus a startup
script. The fact that I will use Eclipse as development tool should not
matter.
    
    Once I have the UI client working again, I'd love to hash out the core scm API
    with you, Mark, Dave and the other interested parties --

I will wait for your changes.

Regards,

Rodolfo 
    
-- 

 MAXPROGRAMS
 IBM Business Partner
 Microsoft MSDN Business Connection Partner
 rmraya@xxxxxxxxxxxxxxx
 http://www.maxprograms.com