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

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

Ok, than we will make it so. In any case, for the intermediate release
of SDF 2.6.1, I will use the old
technique of wrapping a linux installer that contains the whole of SDF
in a single jar. The following
release I hope to have implemented the new scheme.

Cheers,

Jurgen

On Wed, Jun 4, 2008 at 3:30 PM, Stan Sutton <suttons@xxxxxxxxxx> wrote:
>
> 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
>
>
> _______________________________________________
> imp-dev mailing list
> imp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/imp-dev
>
>