RE: [stellation-res] Stellation Eclipse integration

["Jonathan Gossage" <jgossage@xxxxxxxx>]

See embedded comments

> Answers to your questions appear below.
> These answers are based on the existing (CLI-based) Eclipse GUI
> client code.  The current plan (hot off the presses!) is to dust off
> the model2 code, rework and complete as appropriate, and
> get a 'real' Eclipse client working as soon as we (I) can.
> I'm not sure that the existing client code is fully functional w.r.t.
> the current stellation.repos and stellation.core code, and given the
> new plan (and well-known issues with the CLI part of our codebase),
> Mark and I would prefer not to update the CLI-based client-- we
> expect we'll get a _reliable_  Eclipse client faster by finishing
> the non-CLI-based client.
>
> This represents a change from the plan proposed last month.
> In August, it seemed that the best approach was to build a WVCM API layer
> for the Stellation core, and then redesign the Eclipse client to access
> Stellation via the WVCM API (rather than the 'model2' core).
> However, as you pointed out earlier in September, we clearly need
> an Eclipse client to effectively use Stellation.  So, just before
> I left last week,  Mark has asked me to restart work on an Eclipse client
> which does _not_ use any of the CLI code.
>
> Over the weekend, I was thinking about a client that would talk directly
> to the existing core stellation code (stellation.{remote,repos....})
> Given recent posts re: the WVCM work, it sounds like Mark may prefer to
> have a client that would talk to a WVCM wrapper for the existing core
> stellation
> code.  That might look something like this:
>
>      Eclipse GUI client <-> WVCM Wrapper<-> stellation.remote <===>
> Stellation server
>
>      (uses Manitoba client-server communication)
>      (uses client-side wrapper over existing stellation codebase)
>
> rather than something like this:
>
>      Eclipse GUI client <-> WVCM Client <= WebDAV/DeltaV ==> WVCM server
>
>      (uses WebDAV/DeltaV HTTP client-server communication)
>      (requires complete overhaul of Stellation client/server code
> to support
>      WebDAV/DeltaV protocols in both client and server).
>
> Mark and I haven't discussed this yet, so I don't know how he's leaning
> currently.
> I'd like to hear what you (and anyone else on the list) thinks about this
> as well.

I am not certain that trying to use a WVCM wrapper is a good idea. The WVCM
semantics are sufficiently different that I believe we could create some
serious problems trying to force fit the current incarnation of Stellation
into a VCM jacket.

I think that we should define a "convenience" API that can sit on top of
either WVCM or our current remote interface
and provides convenient abstractions for the common operations, masking the
specific WVCM semantics would work better. Once WVCM becomes available on
the server side we can look at providing a WVCM based implementation of this
API bridge.

>
> In any case -- I expect to start working on an up-to-date Eclipse client
> shortly,
> as soon as I've worked out the OS upgrade issues and completed the
> repository content updates discussed over the past few days.

I have been giving this whole area a lot of thought recently and I am
currently working on a document, both for our own use, as well as for
submission to the Eclipse Team folks who have scheduled time in M4 for an
evaluation of WVCM.

>
> Now, back to your questions --
>
> At 08:54 PM 9/14/2003, Jonathan Gossage wrote:
> >I have a few questions on the Stellation IDE (which I have not used yet).
> >
> >If I create a new Eclipse project, can I associate it with
> Stellation using
> >the Eclipse Team Sharing mechanism?
>
> Yes.
>
>
> >If I use Eclipse refactoring to move a class from one package to
> another or
> >even from one Eclipse project to another, will Stellation automatically
> >learn about the move?
>
>  From one package to another, yes (and full history is maintained).
>
>  From one project to another, yes (assuming both projects are
> already managed
> by Stellation in the local workspace).  However, the version
> history is _not_
> maintained in that case: it's treated as a deletion in the source
> project and
> as a new file creation in the target project.  This is one of the things
> we'd like
> to fix with the future 'MetaProject' feature (see related Wiki page).
>

I think the whole issue of projects and metaprojects becomes moot given
WVCM. In this world you have workspaces at the highest level and ten
configurations which are somewhat analogous to our current projects.
>

> >Once a class has been moved from one package to another, but before the
> >workspace is checked in, If I do a merge from the repository into the
> >workspace, will Stellation find the moved class properly or will
> it attempt
> >to merge against the old location?
>
> Stellation will merge properly.  Internally, Stellation artifacts are
> managed by
> artifact ID, which is immutable.  Prior to checkin, the local workspace
> resource
> map will show that the artifact ID has been remapped to the new
> name/location.
> During the merge, the local version of the artifact will be
> merged with the
> repository artifact that has the same artifact ID (local resource path is
> not considered).
> Post-checkin, the resource <-> artifact maps for the
> newly-created version
> will show
> that the artifact with the ID in question is now mapped to the
> 'new'  name/location.
> Previous versions will continue to show that that artifact was mapped to
> the old
> name/location in those versions.  This allows us to restore artifact
> name/location as
> well as artifact content when an old version is retrieved.
> (Note: A CompoundArtifact is "the repository representation of a
> directory,
> providing
> a map between names and artifacts" for a particular BranchImage,
> or 'version'.
> A local workspace uses somewhat different mechanisms:
> see ...stellation.cli.workspace.Project and its use of _pathMap
> and _IDmap
> variables).
>


Regards

Jonathan