| OT/Equinox changes for Eclipse Luna [message #1074706] |
Sat, 27 July 2013 10:22  |
 Stephan Herrmann
Messages: 872
Registered: July 2009 |
Senior Member |
|
|
Hi folks,
this is a first heads-up about ongoing changes in OT/Equinox for the next annual release aka Eclipse Luna:
In my first build against a current integration build of the Eclipse SDK I noticed that our existing implementation of OT/Equinox is dead because of some recent changes in Equinox.
The good old "Adaptor Hooks" [1] are no longer supported in their existing shape. For OT/Equinox this is a breaking API change, although Tom rightly responds that the corresponding packages were marked as "x-internal".
For Object Teams this means we couldn't even build against the new osgi framework, unless we rewrite OT/Equinox against the new API org.osgi.framework.hooks.weaving.WeavingHook.
The move to the new hook - which is part of the OSGi standard - is of course a good thing that should eventually help also for compatibility with other weavers like AspectJ. So, I bit the bullet and took my draft implementation from earlier this year and right now I'm in the process of fleshing out a brand-new implementation of OT/Equinox. See the bug [2] for details and progress.
Ideally, this rewrite would be a purely internal change, but unfortunately, I won't be able to make these changes ina 100% backward compatible way.
Right now the following two changes seem necessary:
(1) all packages containing one or more teams to be woven into another bundle must be exported from their bundle
(2) binding a nested team will require using the binary name (using '$' as a separator for Outer$Inner), rather than the source name ('.'-separated).
For (2) the IDE should hopefully flag an error and maybe even provide a quick fix [3].
For (1) I'm in the process of investigating alternatives. I don't like the fact that we'd need to require redundant specification: for each team declared in an aspectBinding (via the extension point), we'd redundantly need an export of the team's package in the bundle manifest.
In a first experiment I'm using the following specification in the manifest:
Export-Package: org.eclipse.objectteams.otequinox.internal.branding;ot-aspect-host="org.eclipse.objectteams.otequinox.branding"
This declaration would say that the package o.e.o.o.i.branding is exported only as an aspect package, visible only for base-to-aspect calls from woven code, and the bundle-name in the ot-aspect-host attribute would disambiguate in case of split packages. Don't worry about the details at this point. One goal of these experiments is to find out whether we can fully migrate the declaration via the extension point "aspectBindings" towards declarations in the manifest, which would hopefully avoid the mentioned redundancy. But these are preliminary ponderings.
If this migration works out well, we'll have the benefit that OT/Equinox should have much lower coupling to Equinox, so one day it should actually run on other OSGi containers as well.
It seems that a few features will, however, never fully make this move. My idea is to provide these features with a "discouraged" warning, saying that these are again based on non-official "API" of Equinox, which is not portable and may break in the future. In this category I currently see these features:
- forced exports (no way to implement this in a 100% standards conform way)
- aspect bindings without package exports (I may actually be able to hack around the restriction mentioned above)
I can't yet say anything about migration from extension point to manifest headers,
so please stay tuned for updates.
best,
Stephan
[1] http://wiki.eclipse.org/Adaptor_Hooks
[2] https://bugs.eclipse.org/413856
[3] https://bugs.eclipse.org/406518
|
|
|
|
Powered by
FUDForum. Page generated in 0.01525 seconds
] 
Search
Help
Register
Login
Home
