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

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

Hi Bob,

You had some good questions. Let's see.

>>  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.
>>
>
> This is the part I don't get. Why not include *all* of the platform-specific plugin
> fragments in the feature, per Eclipse convention? Each plugin fragment identifies
> the platform it's intended for. Unless you're addressing the issue that the target
> platform constraints (e.g. "os", "arch", etc.) aren't specific enough. But then,
> regardless, how are inter-feature dependencies going to work wrt platform-
> specific fragments? How is the Update Mangler going to figure out what to
> install?

A. Why not make one feature that contains all plugins, which have all fragments?
B. How are inter-feature dependencies going to work wrt platform
specific fragments?

A. Because SDF, and the rest of The Meta-Environment is a product family out
  of which we make many different selections to create product. SDF
is only one
  of these products. Actually, normally Box is not part of the SDF
release, but I
  changed this for 'convience'. There is either many many
convenience 'features'
  that each bundle one product out of our family - maintained
manually - or we defer
  the selection of the product to the user via the update site. Last
argument;
  in several cases we found out that colleagues made their own
unexpected products
  by selecting parts of our stuff, and those colleagues highly
appreciate the fact that
  they can limit their dependencies on something smaller rather then
our entire
  toolset (also in terms of deployment dependencies, not just run-time).

B. Because each plugin corresponds to exactly one feature, and all plugins have
  a fragment for each supported platform. A feature is a plugin, is
a fragment.
  So Eclipse will select the correct fragment, because it selected the correct
  feature, which contains only one plugin, for which only one
fragment is available
  on the platform that the user has.

>>  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).
>>
> Sounds cool. Can you post more details on this?

My idea is to have an extension point for C-based plugins that explain
stuff about the directory
structure inside the bundle: binary path, library path, include path,
other resources. By default it will assume
/bin, /lib, /include, /share as top level directories in the bundle.

The plugin that implements this extension point will:
- maintain a registry of 'C plugins'
- provide an API for calling binaries installed in these plugins by:
   - setting up the right environment for them (PATH, LD_LIBRARY_PATH)
   - providing a way to communicate with the binaries via pipes, and
possibly sockets.
- the plugin will assume inter-plugin dependencies exist between the
C plugins,
  and will act such that each plugin will be able to find libraries
installed another.
  Possibly it extracts information from the MANIFEST.MF files to do this.

This API will not abstract from the commandline options of these
tools, instead it is a
tiny layer around System.exec. The programmer can use it to quickly
wrap the commandline
tools in a class that supports  the functionality of the C tool in a Java API.

Cheers,

Jurgen