[stellation-res] A minor proposed reorganization

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

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

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