Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] Stellation Eclipse integration 
Jonathan,

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.
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.

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).



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). 

        - Jim


--
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

Back to the top