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 Wim,

On 2/19/2011 11:08 AM, Wim Jongman wrote:
Hi,

Do you want to make a set of features so that end-users can cherry-pick the components they want. Like we currently have @ http://download.ecf-project.org/repo

No, I think the basic structure of these component features are fine/ok.  They possibly could use some tweaking, and if others have suggestions about changes then we can change them.

What I was suggesting was another/new feature (that was also a top-level category) that was something like a

'Remote services target components' 

...that would provide the moral equivalent of the ECF remote services SDK...but not assuming Eclipse as the target platform (which the current top-level Target Components feature does).  The intention would be to allow easier ECF remote services installation into non-Eclipse target platforms...and more visibility by being a category (which appears when they have the category check box selected).

Scott



Regards,

Wim

On Fri, Feb 18, 2011 at 6:25 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Folks,

Currently ECF has essentially 1 top-level feature:  Eclipse Communication Framework Target Components (formerly called the ECF SDK).  This has traditionally had almost all of ECF from Eclipse Foundation...i.e. all the various APIs (remote services, discovery, call api, sync, shared object, presence, etc), as well as almost all the providers, the documentation, as well as the example apps (both Eclipse-based UI and no-ui examples).

Although convenient for usage for Eclipse installation (i.e. install everything into Eclipse), this feature is not at all convenient for people that want to add ECF to the target platform...e.g. for OSGi server-side remote services development...because it includes a lot of code that depends upon Eclipse UI and other things).  One reason it's not convenient is that the target platform resolution (by default) has the 'Include required software' check box selected, and the current ECF Target Components requires parts of Eclipse.  If the user de-selects 'Include required software' all the non-Eclipse parts of ECF (e.g. remote services) will be used/usable just fine once installed...but it would be much more convenient if the user could have 'Include required software' checked, and still easily install ECF/OSGi remote services for use in their target platform.

This is the use case I would like to simplify:  Using ECF in non-Eclipse target platforms

I think we need a top-level feature (or features) to make it easier to add the non-Eclipse parts of ECF...specifically OSGi remote services...to a target platform that is not Eclipse (e.g. OSGi servers).  I propose that we do this for ECF 3.5 release, as it would/will make consuming ECF/OSGi remote services (and remote services admin newly introduced) *much* easier for people using ECF for non-Eclipse target platforms.

Comments?  I think we should discuss this some on the mailing list over the next few days...and at the next ECF conf call [1] we can discuss and decide.

Thanks,

Scott

[1] http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#Next_Conference_Call:__Monday.2C_February_21.2C_2010_-_1800_UTC.2F10:00am_pacific





_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top