RE: [stellation-res] A minor proposed reorganization

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Sat, 2002-12-07 at 18:06, Jonathan Gossage wrote:
> > >-----Original Message-----
> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > >Chu-Carroll
> > >Sent: December 7, 2002 11:05 AM
> > >To: Stellation-res
> > >Subject: [stellation-res] A minor proposed reorganization
> > >
> > >
> > >
> > >I'd like to propose a slight reorganization of the code.
> > >
> > >As we've discussed in the past, we're going to be gradually moving
> > >into a more Eclipse-based way of driving Stellation. We're going to
> > >be turning core into more of a true plugin, and using the Eclipse
> > >launcher for running the command line tool. (For an example of
> > >a system built this way, take a look at the current version of the
> > >AspectJ compiler, which is implemented as a set of Eclipse plugins.)
> > >
> > >Anyway... Looking at the code with an eye towards this change, it
> > >looks mis-structured, not in the sense of there being anything wrong
> > >with the structure from a Java point of view, but in the sense of it
> > >being improperly divided into plugins from the Eclipse point of view.
> > >
> > >The problem, as I see it, is that from an Eclipse-centric point of
> > >view, what we're calling core is actually several distinct components:
> > >the true core (org.eclipse.stellation.repos and friends); the server and
> > >remote-access code; and the command-line client.
> > >
> > >So I'd like to re-structure the current core into the following
> > >components:
> > >- org.eclipse.stellation.core for the "true core", which will contain
> > >  the basic repos code, the database code, the artifacts and artifact
> > >  agents, and the interfaces for components that interface with
> > >  the core, like inputs and outputs.
> > >
> > >- org.eclipse.stellation.commandline for the command-line client, which
> > >  will contain the command-line workspace, the workspace-specific
> > >  input and output implementations, and the command-line script tests;
> > >  and
> > >
> > >- org.eclipse.stellation.remote, for all of the code involving
> > >  remote access: the comm engine, the remote handle, and the
> > >  server. (This could also be split into engine, server, and client,
> > >  but I think that's creating too many tiny plugins. However if there's
> > >  a consensus that once we're dividing things, this should be separated
> > >  as well, I won't fight it.)
> > >
> > >If you all agree, I'll do this in a way that preserves the ability to
> > >build the system from the command-line using a single ant build script.
> > >
> > >I think the positive side of this is clear: it makes things easier to
> > >work with in Eclipse; cuts the side of the core package which is
> > >currently rather awkward in eclipse; and makes it much easier to set up
> > >the eclipse-launcher based versions of things.
> > >
> > >The negative side is, I think, that it makes some things more awkward
> > >for people working from the command-line on things that cross the
> > >boundaries created by this. For example, if you're working on I/O
> > >components for the command-line, then you might be working on some
> > >stuff in the core component, and some stuff in the workspace component.
> > >If you're debugging something involving remote access, you might need
> > >to be looking at code in the core, the remote-access, and the
> > >command-line workspace plugins, which will be located in three
> > >different source-directory hierarchies in the three plugins.
> > >
> > >Comments?
> > >
> > >	-Mark
> > >
> > >
> Your proposal is almost the same as one that I presented in a discussion
> with Jim some weeks ago. I think this is a better structure, both from an
> Eclipse plugin perspective and from the viewpoint of possibly integrating
> Stellation into other IDEs' down the road.

I didn't mean to take credit for anyone else's suggestions; I've been
unbelievably swamped for the last 6 or 8 weeks, and I haven't been
following all of the discussions on the list. I missed the one where
you suggested this, or I would have given you credit for it.

> So long as all the plugins are in the same workspace I don't see a big
> problem with needing to debug through multiple plugins, but then I am used
> to this kind of thing :-).

For those of us who are Eclipsians, this kind of thing is no big deal;
in fact, Eclipse was intended to do things this way, and so this kind of
subdivision often makes it easier to work with a project in Eclipse. My
once concern is that we do have at least two people (Dave and Florin)
who are working, at least part time, without eclipse, using standard
command line tools. In you're working outside Eclipse, then dealing
with code separated this way can be painful.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx