Re: [ecf-dev] ECF 3.5 top-level features...for target platform usage

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 02/26/2011 12:51 AM, Scott Lewis wrote:
> Hi Folks,
> 
> Although there are admittedly a number of things remaining to be done
> WRT ECF features refactoring (e.g. the previously-expressed
> rerquirements [1] and [2] pointed to by Markus), I'm not aware of
> resources to work on these refactorings in the short-term, and so I
> don't think we are going to be able to address them for ECF 3.5.
> 
> I suggest that we defer these additional requirements for ECF 3.5
> (review materials due March 2, review on March 9, and release on ~March
> 14) and focus on one further change:  Create a top-level feature
> category for 'ECF Remote Services Target Components'.

Agreed, we don't have the resources to do it all for 3.5. But we must
make sure, we don't make those enhancements impossible with what we do
now. To summary the requirements we have so far, are:

- Headless ECF features that leave any UI or EMF dependencies.

To me, this req sounds a lot like what a "target component" is supposed
to mean. WRT "Remote Services Target Components" is the feature intended
to include UI dependencies?

- Base feature for core bundles

IMO this one won't interfere with a "Remote Services Target Components"
feature.

> So first a little background
> 
> Currently, if the user adds the ECF repo to the Install Manager, and the
> 'Group items by category' check box is selected, the ECF repo looks like
> this:

Unless "Group items by category" is turned off. If turned off, one gets
a much more detailed view of the ECF features. Personally I think
consumers who knows what they want, will like no categories better.

> Eclipse Communication Framework (ECF)
>     ECF 3.5 Patch for Eclipse
>     Eclipse Communication Framework Target Components
>     Source for ECF 3.5 Patch for Eclipse
>     Source for Eclipse Communication Framework Target Components
> 
> First, I suggest that we change the working of these to read:
> 
> Eclipse Communication Framework (ECF)
>     Core Patch for Eclipse
>     Target Components for Eclipse
>     Source for Core Patch for Eclipse
>     Source for Target Components for Eclipse
> 
> Further, I suggest that we (somehow) create a new category (and their
> two Source feature categories)
> 
>     Remote Services Target Components
>     Source for Remote Services Target Components
> 
> So the whole thing (at the top-level category on) would look something
> like this:
> 
> Eclipse Communication Framework (ECF)
> 
>     Core Patch for Eclipse
>     Target Components for Eclipse
>     Remote Services Target Components
>     Source for Core Patch for Eclipse
>     Source for Target Components for Eclipse
>     Source for Remote Services Target Components
> 
> The idea being that the (new) Remote Services Target Components would
> not necessarily be for Eclipse (i.e. using the Equinox SDK)...and that
> if loaded into a PDE Target Platform (rather than installing into
> Eclipse), the Remote Services Target Components would be
> 
> 1) Installable into a target platform that did not already have all of
> Eclipse (i.e. just required the Equinox SDK)
> 2) Would complete the addition to a target platform even if 'Include
> required software' is selected (this is the default in the PDE target
> platform 'Add Content' wizard for adding from 'Software Sites').
> 
> The idea here is that if someone wanted to add ECF remote services to
> their target platform (not necessarily install it into Eclipse), that
> all they would have to do is to add the ECF repo as a software site,
> select the Remote Services Target Components (with 'Group by Category'
> and 'Include required software' check boxes selected by default), click
> 'Finish', and all the bundles in the Remote Services SDK (already a
> feature that we have) would be installed into the target
> platform...along with their requirements (as per 'Include required
> software').

Which bundles will be part of the "Remote Services Target Components"
feature? Or will it just consist out of nested features?

> Now I know that this interacts with the issue of the 'feature version
> exact match issue', but I'm not clear on what we can do about that (i.e.
> can we turn the relaxed matching in our own build back on?).

Given the bugs in the target platform editor and the little interest
there is to fix it, I do not expect relaxed version ranges to be usable
in Eclipse anytime soon.

> So, what else do people think?  The idea here is to make it as simple as
> possible to use the existing Remote Services SDK feature (or a new one
> if necessary), to install into a target platform, with 'Include required
> software' checked...and not have p2 complain about install dependencies,
> etc.

Markus