Re: [stellation-res] A complete plugin setup?

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

On Tuesday 23 July 2002 03:57 am, Ringo De Smet wrote:
> Hello guys,
>
> At the moment, the command line version and the Eclipse plugin version
> are quite different to setup. The cli version uses batch files to set
> the class path etc. I've been thinking if it wouldn't be possible to
> create a complete Eclipse plugin setup for client, server daemon and
> Eclipse Team integration. I think it is!
>
> The client would be comprised of the Eclipse launcher and the following
> plugins:
> - org.eclipse.core.boot
> - org.eclipse.core.runtime
> - org.eclipse.core.resources (?)
> - org.apache.xerces
> - org.apache.log4j
> - org.jdom
> - org.eclipse.stellation.core
> - org.eclipse.stellation.client (to be created)
>
> The server daemon would be the following set of plugins:
> - org.eclipse.core.boot
> - org.eclipse.core.runtime
> - org.eclipse.core.resources (?)
> - org.apache.xerces
> - org.apache.log4j
> - org.jdom
> - org.eclipse.stellation.core
> - org.eclipse.stellation.server (to be created)
>
> The full Team integration would add the following plugins to the
> Eclipse distribution:
> - org.eclipse.stellation.core
> - org.eclipse.stellation.scm.model
> - org.eclispe.stellation.scm.ui
>
> In the above cases, the new client and server plugins will contain the
> main Eclipse application to launch (implements IPlatformRunnable).
> There already exists a launcher on every platform Eclipse exists for,
> so we could get rid of the unix shell scrips. In the three scenario's I
> was thinking of adding the RDBMS connection management plugins from the
> ECLDBTool project(1).
>
> Another benefit is that we only have to support one programming model:
> the plugin model!
>
> Comments?

I haven't looked at the Eclipse launcher framework, so I can't honestly
judge how feasible this is. In theory, I think it sounds terrific. 

In practice, my main questions are about startup performance. Eclipse
starts dreadfully slowly - it's my biggest complaint against Eclipse. Our
command-line tool is no speed demon already. I'd hate to slow it down
even more. Do we have any idea of whether using an Eclipse launcher
to run the command-line client would make it worse? If no one has
tried anything like this, we need to do some tests to find out what the
performance impact will be.

Assuming it's not a significant performance impact, I think it's a great
idea. Particularly as we start to implement some of the more advanced
functions, it's going to get harder to manage the codebase to keep
it running smoothly in two very different contexts. If we can get rid
of that, and just have it always running in an Eclipsey context, I think
it would really help make our lives easier.

As far as the ECLDBTool goes: it looks like a nice DB abstraction tool.
The repository core, is mainly my piece of the system, and I would
be delighted to have it integrated. But from my look at the website, it looks
like abandonware. If it actually works, and it's not going to be a problem
to maintain (I'm assuming we'll have to maintain it, due to its apparent
abandonment by it's original author), then we should go for it.

	-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