Bugzilla – Full Text Bug Listing
| Summary: | Modularize XMPP provider WRT to remoteservices and datashare dependencies | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Markus Kuppe <bugs.eclipse.org> | ||||||||||
| Component: | ecf.providers | Assignee: | Markus Kuppe <bugs.eclipse.org> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | slewis | ||||||||||
| Version: | 3.3.0 | ||||||||||||
| Target Milestone: | 3.4.0 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 321691 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Markus Kuppe
Created attachment 175833 [details]
split provider.xmpp into provider.xmpp, xmpp.remoteservice, xmpp.datashare
Created attachment 175834 [details]
mylyn/context/zip
Created attachment 175835 [details]
frament projects
I don't have any fundamental objections to modularizing the xmpp provider, but I want to ask a couple of questions: 1) What's the main motivation/use cases for this? Is it reducing the runtime size of the provider (for some uses)...use on the server...just reducing dependencies...something else? One possible side effect of doing this is that for some consumers it creates the extra complication of having to build/deploy additional bundles. I know this is easily overcome if we create features/repos for such use cases (and we should do so, I believe), but it still may make the xmpp provider slightly harder to use. 2) I'm not really sure about the use of fragments for this modularization. It seems to me that having separate bundles would be better. (In reply to comment #4) > I don't have any fundamental objections to modularizing the xmpp provider, but > I want to ask a couple of questions: > > 1) What's the main motivation/use cases for this? Is it reducing the runtime > size of the provider (for some uses)...use on the server...just reducing > dependencies...something else? Exactly, for consumers that just want to use XMPP as a presence container it's just to coarse grained. Dragging datashare and remoteservices in just to implement and adapter is disappropriate. > One possible side effect of doing this is that > for some consumers it creates the extra complication of having to build/deploy > additional bundles. I know this is easily overcome if we create features/repos > for such use cases (and we should do so, I believe), but it still may make the > xmpp provider slightly harder to use. [0] is a new feature that contains provider.xmpp, smack as well as both fragments. > 2) I'm not really sure about the use of fragments for this modularization. It > seems to me that having separate bundles would be better. Contrary to bundles, fragments share the life cycle with their host and thus make deployment for consumers easier. Given that the two fragments just add an adapter, I do not believe we need a separate life cycle for them. [0] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/releng/features/org.eclipse.ecf.xmpp.feature?h=origin Fix released to HEAD (If we find that the fragments need a bundle life cycle of their own, please reopen and I will turn them into bundles. Created attachment 175906 [details]
mylyn/context/zip
(In reply to comment #7) > Created an attachment (id=175906) [details] > mylyn/context/zip In my local workspace, I'm getting the following error Description Resource Path Location Type Project 'org.eclipse.ecf.provider.xmpp.datashare' is missing required source folder: 'src' org.eclipse.ecf.provider.xmpp.datashare Build path Build Path Problem Although src/ exists in CVS, Eclipse's CVS implementation appears to skip empty folders. Thus I have just removed src/ from the .classpath/build.properties. |