[platform-scripting-dev] scripting plugin-development environment setup?

["Thomas L Roche" <tlroche@xxxxxxxxxx>]

I'd appreciate any guidance (etc) anyone could provide regarding using
eclipse scripting and ant to setup eclipse plugin-development
environments. Why I ask:

My workgroup at IBM uses an "old-style" self-hosting setup. (Please
don't ask me why: I don't know, and it's not my decision to make.
However it appears, from e.tools traffic, that mine is not the only
IBM group doing this.) This causes one to periodically endure
migration to new "target builds," which is tedious. If you're familiar
with the process, skip to </explanation>; otherwise:

<explanation>

We work within a development environment (call it "devspace" since it
maps to a filespace) and debug our work in a "self-hosted" environment
launched from the devspace (call that the "runspace"). One's devspace
is based on the plugins included in a given target build, and target
builds get generated ~daily, in various flavors (WSED, WSAD, EGL, etc,
with various sub-flavors of packaging). (One who is particularly
unlucky (like me) may need to pull plugins into their devspace from
more than one target build.) These are one's "binary plugins"; one
will then add to one's devspace the "source plugins" on which one (or
one's team) is actually developing. (One who is particularly unlucky
(like me) may need also need source plugins from less-stable projects
on which one is dependent.) One may also, if paranoid (and there are
many of us :-), want to backup one's old runspace, and create a new
one, possibly pre-seeded with some runtime context.

Builds are large (~500MB, zipped), so all this involves a lot of time.
E.g. FTPing a target can take several minutes (or way more, depending
on network and server load), unzipping a target takes ~10 minutes,
importing the unzipped plugins into eclipse takes ~25 minutes,
rebuilding a completed environment takes ~5 min, etc. Furthermore,
each step involves some user involvement: one can't just set it
running and come back in an hour.

Worse yet, builds are sometimes mysteriously unstable (e.g. debugging
is either broken or very slow), so one may go through several candidate
targets before finding one on which productive work can be done.

</explanation>

So I'd like to script the setup process, to make it "fire and forget":
e.g. one could launch the process before leaving for lunch. The basic
sequence of tasks is something like this:

0 ftp a build's zipfile (call it "build.zip") from some user-inputted
  site URI.

1 unzip build.zip to some user-defined directory (call it the "target
  directory"). Typically, on windows, this is also mapped to a drive via
  'subst', so that any currently-active target directory can be
  addressed by the same path (i.e. w:\eclipse\plugins).

2 start eclipse. Essentially this is starting a JVM: currently we use an
  eclipse.bat that does something like

  %JRE -Xmx384M -Xms256M -verify -cp startup.jar
  org.eclipse.core.launcher.UIMain -application
  org.eclipse.ui.workbench -data %DEVSPACE% %1 %2 %3 %4 %5 %6 %7 %8 %9

3 set one's preferences; notably, turn off autobuilding. (Otherwise
  subsequent processes become much slower.)

4 tell eclipse to import some user-defined subset of "root" target
  plugins: eclipse then figures out the list of "root and required"
  plugins (i.e. the roots, plus all their dependencies)

5 add user-defined (CVS) repositories (in Team perspective)

6 add one's source projects, from those repositories, to the devspace

7 Rebuild All

I believe steps 0-2 are easily doable with ant. But I know almost
nothing about automating the interaction with eclipse, required for
steps 3-7.

Could I do this with the eclipse scripting extensions? If so,

Do you know of anyone who has done this? or something similar? If not,

Do you have any suggestions about how to do this?

Your consideration is appreciated, Tom Roche <tlroche@xxxxxxxxxx>