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

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

Hi Bob,

>> A. Why not make one feature that contains all plugins, which have all fragments?

> Actually, this isn't what I was suggesting. Let me try to rephrase.
> I'm suggesting the following structure:
>
>  - For each SDF "package" (which I take to mean an installable unit of SDF
> functionality):
>    - A single feature, containing:
>       - one plugin for the Java code (if any)
>       - one plugin fragment for each target platform
>       - dependencies as appropriate on other features
>
> Does this change your answers at all?

If I'm not mistaking, this is exactly what I was suggesting too. We
could be misunderstanding each other.
So I'll give an example. Let's say the SDF product consists of these
"packages" (which are indeed installable units of SDF functionality):
  - aterm (C package)
  - aterm-java (Java package)
  - sglr (C package, which depends on aterm)
  - jsglr (Java package, which depends on aterm-java)
  - sdf (C package, depends on sglr and jsglr)

You and I are suggesting that:
 - each C package, (aterm,sglr,sdf) becomes a fragment (and
corresponding plugin, since a fragment does not exist without a
plugin): aterm-fragment, sglr-fragment, sdf-fragment, aterm-plugin,
   sglr-plugin and sdf-plugin.
 - each Java package (aterm-java, jsglr) becomes a plain old plugin
 - for each C and Java package there is one feature that contains it's
corresponding plugin: aterm-feature, aterm-java-feature, sglr-feature,
jsglr-feature, sdf-feature.
   The feature dependencies will be the original package dependencies,
so sglr-feature will depend on aterm-feature, etc.

If this is so, we understand each other ;-) Email is a 'nice' medium.

Cheers,

Jurgen