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

[Stan Sutton <suttons@xxxxxxxxxx>]

I think this all sounds great.  Good
ideas, good questions, good answers.

Regards,

Stan

Stan Sutton, Ph. D.
IBM T. J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532 USA
telephone:  1-914-784-7316, FAX:  1-914-784-7455, T/L 863
e-mail:  suttons@xxxxxxxxxx, Stan Sutton/Watson/IBM@IBMUS

"Jurgen Vinju" <Jurgen.Vinju@xxxxxx>
Sent by: imp-dev-bounces@xxxxxxxxxxx

06/04/2008 02:24 AM

Please respond to
IMP Developers List <imp-dev@xxxxxxxxxxx>

To	"IMP Developers List" <imp-dev@xxxxxxxxxxx>
cc
Subject	Re: [imp-dev] SDF,        Box (and ASF+SDF Meta-Environment) deployment on Eclipse platform plan

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
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev