RE: [stellation-res] A minor proposed reorganization

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: December 7, 2002 9:02 PM
> >To: Stellation-res
> >Subject: RE: [stellation-res] A minor proposed reorganization
> >
> >
> >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.
> >
Not worried about credit, just results. Just trying to say that I agree
whole-heartedly. In any case the points were enbedded inside a larger
architectural discussion so they might have been missed anyway.


> >> 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
> >
The last time I worked with command line tools on a large scale was in my
QNX days in the mid-eighties so I guess that I may have forgotten the
problems. Out of curiousity, are they working this way by choice or
necessity? Because I am interested in tool development, I like to understand
why different environments are chosen.

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx