Community
Participate
Working Groups
Build Identifier: Presently, noticeable amount of certain bundles/plugins in their MANIFEST.MF express dependencies on swt, ui, jface etc... in the form of Require-Bundle. As an example org.eclipse.e4.xwt can be considered. It will provide a smooth compatibility for such plugins if target components will include proxy bundles as an option to be included in target environment. Reproducible: Always Steps to Reproduce: N/A
Created attachment 178281 [details] Plugin projects wich are proxy bundles
First of all, a big thanks for your efforts to make XWT work with RAP! Regarding the problem with Require-Bundle dependencies: we are aware that this is an inconvenience. We once considered re-using the original bundle ids for RAP but decided not to so. Basically because that would violate the concept of an id - e.g. org.eclipse.ui and org.eclipse.rap.ui are not *id*entical, and thus should not have the same id. Doing so would make it hard to tell original and RAP bundles apart when working with different target platforms. Since the proxy bundles you suggest have the same problem, I think including them in RAP is not an option. Our recommendation for plug-ins with Require-Bundle dependencies is to express a dependency to both, the original and the rap bundle and mark both dependencies as optional. Would that work for XWT? Or wouldn't Import-Package be the better alternative for XWT anyway?
Thanks for appreciation. As for the Proxy (or probably Compat?) bundles. I agree that including them in RAP target could make it hard to distinguish apart which exact bundles the dependents were developed against. Still the XWT is not the only plug-in which uses required bundle. I have come across the same problem when used o.e.ui.navigator (Common Nvigation Framework), o.e.jface.text. Likely there are others. So the are 2 options in case when developer decides to use those bundles: 1.) Every project caries out its own set of Proxy(Compat) bundles which do reexport. In this case if the project has to be shared to community it will also include the set of Proxy(Compat) bundles. Several projects will include exactly the same Proxy(Compat) bundle sets which will lead to unnecessary duplication. 2.) The set of Proxy(Compat) bundles may be available as an additional feature of RAP which can be included or not in the target platform. The most important is that they can be made available for downloads as part of target definition. This will eliminate duplication effrots/issues from the previous case. The target platform management consider the certain update-site/p2 repo along with optionally specified versions of bundles. It is possible to mark the qualifier part of version for Proxy(Compat) bundles with "RAP-Compat". Interdependencies of those bundles can be also expressed with "RAP-Compat" in the bundle versions. This option makes "SingleSourcing" concept much closer to reality. There is another interesting benefit. It is possible for developers to create fragment bundles attached to Proxy(Compat) bundles with those fragments having implementation of parts of the original API (For example StyledText :) missed from the RAP. After the implementation of such API can be considered mature it may be easily transferred to the original RAP bundle. If you agree on the 2nd option I can atached already developed set of these version qualified bundles with the sample fragment bundle and with pom.xml files to build an update site with Tycho maven plugin.
