Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF 3.5 top-level features...for target platform usage 
Hi Markus,

On 2/26/2011 2:04 AM, Markus Alexander Kuppe wrote:

<stuff deleted>

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.


I assume you mean 'leave out'.


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?
No...I was thinking of it as only including components for remote services...which don't have UI dependencies at all, afaik. 


- 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.
Perhaps you are right, but the default of 'Group items by category' is on, so I expect that many/most people will just use the default. Those who know what they want will turn it off, and get the detailed list. 



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?
I was *thinking* that this would be the same set of bundles that are in the org.eclipse.ecf.remoteservice.sdk.feature. 



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.
That sucks. Please post the bug here, so that we can join/vote for it, and register our displeasure at the lack of interest in fixing it. 

Thanks,

Scott

Back to the top