Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] refactoring remote service features

Here's a question:

Currently the remote services sdk includes both the remoteservices examples feature and the eventadmin examples feature.

Would people prefer that the sdk (which is currently our remoteservices 'all-in-one' feature) include both these example features...or exclude them?   Another option...we have another remoteservices 'all in one'/sdk-like feature (i.e. with the various OSGi/API bundles and with the provider impls)...but without the examples.

The default route...i.e. what I will be doing unless there is reason not to...is to leave the examples features as part of the all-in-one remoteservice sdk feature (org.eclipse.ecf.remoteservice.sdk.feature).   Just to be clear, with the refactoring that's already taken place, people can install the rs sdk feature and get everything (relevant to remote services), OR they can take a piece meal approach...e.g. select rs/rsa + specific a specific provider(s)...e.g. zookeeper, r-osgi, etc...and these will now automatically pulli in/install all the required APIs and libs.  So the question above is really whether we should have an rs sdk without examples.

Thanks,

Scott

On 2/6/2014 2:50 PM, Wim Jongman wrote:
Scott this sounds like a great plan. It is exactly what we do with Nebula. Each widget has its own feature, there is one loose example feature and a combined feature that pulls them all in. 

Cheers,

Wim



On Thu, Feb 6, 2014 at 7:25 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Folks,

There has been progress on the ECF 3.8.0 feature refactoring bug [1], and now I'm working on refactoring the remote services set of features.

Currently, we have a 'remote services sdk' feature (org.eclipse.ecf.remoteservice.sdk.feature) that essentially includes all the other remote service features.  Just to be clear, all of these are able to run on both Equinox and non-Equinox frameworks, in Eclipse or on some other (e.g. OSGi server) runtime.   Summary is:

API:  core, discovery, remoteservices,  remoteservices.rest,  osgi rsa, servlet, soap
Providers:  discovery providers (e.g. slp, dnssd, zookeeper, zeroconf), and distribution providers (generic, r-osgi)
Examples (e.g. timeservice, event admin examples,  others, chat, etc).
Event Admin:   The ECF distributed event admin
Supporting API:  sharedobject, datashare
Generic Server:  generic server API and impl

All of the above features are included in the current org.eclipse.ecf.remoteservice.sdk.feature.

I'm thinking about how to reorganize things for [1] and I would like some feedback.  Here's what I'm thinking:

1) Using/creating a finer-grained set of features...so that people can more easily get just the OSGi remote services APIs (discovery, distribution, rest, osgi, and supporting) and
2) The combination of providers implementing these APIs (discovery and distribution) that they wish to install
3) Remove Examples, Event Admin, and Generic Server from these finer-grained features (people will, of course still be able to get the examples)
4) Still provide an 'all-in-one' feature (org.eclipse.ecf.remoteservice.sdk) that contains everything.

With the work on 409787 that's already been done, we're not at all far from the 'finer-grained' as expressed above...as we have these finer-grained features for discovery API and providers, as well as distribution/remote service API and providers.

Please let know...as a comment on bug [1] if there are other aspects to the restructuring of remoteservices that are important to you that aren't reflected above.

Thanks,

Scott

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=409787




_______________________________________________
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