[imp-dev] SDF, Box (and ASF+SDF Meta-Environment) deployment on Eclipse

["Jurgen Vinju" <Jurgen.Vinju@xxxxxx>]

Hi guys,

This our idea of how we are going to deploy the SDF stuff on the
Eclipse platform in the future. The issues are:
  - most of SDF is written in C: binaries that communicate via files,
and dynamically loadable libraries.
  - some of SDF is written in Java, more of Meta-Environment is written in Java.
  - SDF is one selection out of a large collection of components
("packages") that depend on each other.
  - we have an infra-structure which does component composition for us
(both source and binary composition),
    it could also generate Eclipse fragments, plugins and features for us.

So, the plan is:
  1. Make all "packages" Eclipse plugin projects (already done: by
adapting our build environment to generate META-INF and plugin.xml
files for the
      C packages.)
  2. For each package, generate a FRAGMENT .jar file that contains the
META-INF and the C binaries and scripts produced by the package
  3. For each package, generate a PLUGIN .jar file that only contains
a META-INF file. This can be empty for C packages, because C packages
only have platform dependant code.
      For Java packages, this will contain the Java class files and
code as usual.
  4. For each package, generate a feature.jar file that contains the
feature.xml and META-INF that only has one plugin in it, and use our
"package"
      dependencies for the feature dependencies.
  5. Provide a plugin project that has an extension point for
registering C packages with binaries installed in them, which handles
PATH and other settings
      and provides a convenient class for communicating with such
tools via pipes, files or maybe even sockets (can be constructed from
the current SDF Tools class).

Drawbacks:
  - none that we see, apart from a rather strange one-to-one mapping
between plugins and features that might surprise some people.

Benefits:
  - The Eclipse update site feature will allow the user to select
parts of SDF as he sees fit, because the feature dependencies reflect
our package dependencies.
  - The evolving implementation of SDF, and other stuff, will
automatically be reflected in the update site. No overhead for the
maintainers of SDF.
  - It allows for `package by package' reimplementation of C code to
Java (if that is what we would want, but still, it's nice to have the
possibility).

Question:
  - are there any blind spots in our plan; are we missing some kind of
limitation, requirement, or technical detail that might mess up this
little plan?

Cheers,

Jurgen