Bugzilla – Full Text Bug Listing
| Summary: | [releng] xmpp datashare and and remoteservice fragments need to be added to SDK | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Scott Lewis <slewis> |
| Component: | ecf.releng | Assignee: | Scott Lewis <slewis> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bugs.eclipse.org, ilg, wim.jongman |
| Version: | 3.4.0 | ||
| Target Milestone: | 3.5.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 332234, 335787 | ||
|
Description
Scott Lewis
We can either make org.eclipse.ecf.xmpp feature part of SDK or simply add the two fragments to org.eclipse.ecf.core. Thg latter obviously causes less work. +1 for a new feature. (In reply to comment #2) > +1 for a new feature. Please elaborate what you mean by this? ATM there exist two features org.eclipse.ecf.xmpp [0] and org.eclipse.ecf.core [1]. The latter is a included by org.eclipse.ecf.sdk which maps to the release. The former is used for the XMPP CI build. [0] https://build.ecf-project.org/hudson/job/C-HEAD-xmpp.feature/ [1] https://build.ecf-project.org/hudson/job/N-HEAD-sdk.feature/ (In reply to comment #3) > (In reply to comment #2) > > +1 for a new feature. > > Please elaborate what you mean by this? ATM there exist two features > org.eclipse.ecf.xmpp [0] and org.eclipse.ecf.core [1]. The latter is a included > by org.eclipse.ecf.sdk which maps to the release. The former is used for the > XMPP CI build. > > [0] https://build.ecf-project.org/hudson/job/C-HEAD-xmpp.feature/ > [1] https://build.ecf-project.org/hudson/job/N-HEAD-sdk.feature/ Ah, sorry. I understood that you wanted to add the two bundles to the core feature instead of including them in a new feature. As a quick hack so to say. If the ecf.core feature only included core elements then it would be best to add the xmpp feature to the sdk instead of adding the bundles to the core. But after examining the core feature it is clear that it includes many "non-core" plugins so it would not really matter to add one or two more. What is the goal of the feature architecture in ECF? As a consumer, I am always interested in cherry-picking so that I will not pull in stuff that I don't need. (In reply to comment #4) > What is the goal of the feature architecture in ECF? > > As a consumer, I am always interested in cherry-picking so that I will not pull > in stuff that I don't need. Problem is, that the XMPP future isn't really modular either. It simply contains everything that is related to XMPP. However consumer selection is usually motivated by a use case (remote services, docshare, ...) and not by technology. (In reply to comment #5) > (In reply to comment #4) > > > What is the goal of the feature architecture in ECF? > > > > As a consumer, I am always interested in cherry-picking so that I will not pull > > in stuff that I don't need. > > Problem is, that the XMPP future isn't really modular either. It simply > contains everything that is related to XMPP. Yes. > However consumer selection is > usually motivated by a use case (remote services, docshare, ...) and not by > technology. I do not totally agree. If I want to use remote services, I sure want to choose the technology. I don't have use for remote services over XMPP for example and therefore don't want that stuff included. (In reply to comment #6) > > However consumer selection is > > usually motivated by a use case (remote services, docshare, ...) and not by > > technology. > > I do not totally agree. If I want to use remote services, I sure want to choose > the technology. I don't have use for remote services over XMPP for example and > therefore don't want that stuff included. In that case we would have to provide gazillion of different features: RemoteServicesWithXMPP RemoteServicesWithROSGI RemoteServicesWithGeneric ... DocshareWithXMPP DocshareWithSkype DocshareWith... ... PresenceWithXMPP PresenceWithMSN ...
> In that case we would have to provide gazillion of different features:
>
> RemoteServicesWithXMPP
> RemoteServicesWithROSGI
yes, from a releng point of view (not ECF releng obviously ;) that would be very nice. In this way a releng would not have to split the ECF features in new features for deployment of its product.
The modules are fine grained but not the features.
Assigning to myself. *** Bug 335787 has been marked as a duplicate of this bug. *** I'm inclined to include the org.eclipse.ecf.xmpp.feature in the Remote Service SDK (so that the xmpp provider, smack api, xmpp datashare, and xmpp remoteservice fragments) are included in the ECF remote service target components. This can be done by adding org.eclipse.ecf.xmpp.feature as one of the included features to the org.eclipse.ecf.remoteservice.sdk.feature. Then these bundles (xmpp provider, smack api, xmpp datashare fragment, xmpp remoteservice fragment) will automatically appear in the ECF sdk, because the ECF sdk includes the remoteservice.sdk feature. I will also remove the xmpp provider (org.eclipse.ecf.provider.xmpp) and smack api (org.jivesoftware.smack) from the set of plugins included in the ecf.core feature...as these will now be included via the remote service sdk. The org.eclipse.ecf.provider.ui bundle will remain in the org.eclipse.ecf.core feature, so that the xmpp chat UI will be available as part of the sdk. Any comments? Unless people have problems with the strategy outlined in comment 11, I intend to implement this feature refactoring around 9-10am pacific time on Wed, Feb 16. Adding these new fragments to the sdk and other features has been done as described in comment 11. Resolving. *** Bug 335787 has been marked as a duplicate of this bug. *** |