OTVersions/Migrating to Luna

The Luna development cycle introduced three changes of technology, that could potentially require actions from users:

• Migration to a new implementation of the Equinox framework underlying OT/Equinox
• Adoption of Java 8
• Optional migration to a new byte code weaver (OTDRE)

OT/Equinox

During a re-implementation of the underlying Equinox framework, the "Adaptor Hooks", previously used by OT/Equinox, have been withdrawn, requiring a re-implementation also of OT/Equinox. See bug 406518 for details.

Although efforts have been invested to make this change transparent for users a few inevitable changes occurred that may require action from users:

Package exports

During weaving we insert calls from a bound base class to each Team having Role bound to the base class. This implies that the base class must be able to "see" (in the OSGi/ClassLoader sense) the Team class. Previously, this was handled on a per-class basis during custom classloading. In the new implementation we no longer change any class loading strategy (which makes us conform to plain OSGi actually), but in turn this requires a little help from users.

Any bundle defining any Team classes adapting base classes of a nother bundle must now export the package containing the Team. In this export the aspect bundle should identify itself in order to prevent "split-package" issues:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: MyAspectBundle
Bundle-SymbolicName: org.me.AspectBundle;singleton:=true
Bundle-Version: 1.0.0
Require-Bundle: org.eclipse.core.runtime,
 org.eclipse.objectteams.otequinox,
 org.me.BaseBundle;bundle-version="1.0.0"
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: Java2SE-1.7
Export-Package: org.me.teams;ot-aspect-host=org.me.AspectBundle

If this export is missing for a bound Team class, an error is flagged against MANIFEST.MF, for which the following quick fix is offered:

By applying the quick fix, the manifest is changed to:

If you don't want to expose the team package to other bundles, you may consider adding an x-internal or x-friends directive. If the package name contains a segment "internal", x-internal will be added automatically by the quick fix.

Positive side effects

Loading and activation of Teams happens more lazily now, i.e., only when a base class is loaded that is affected by any role bindings. Previously, loading and activation of Teams could lead to eager loading of transitively referenced bundles, thus causing longer start-up times of Eclipse. With the new scheme, Eclipse's lazy loading should be basically restored resulting in shorter start-up times.