Singlesourcing for Eclipse 4.x and Eclipse 3.x

Complementary to Eclipse 4.x Compatibility Layer: What's hot? What's not?

The strategy of moving Eclipse 3.x workbench-dependant code to separate abstract classes was echoed. An example was provided in extending ViewPart with an abstract class that their view implementation then extended. The new abstract class used the 3.x workbench code while the view implementation was insulated. Later that view class can be modified more subtly in removing the extends of the abstract and adding annotations like @Inject to do the same work.

Further, the 3.x-dependant code can be moved to separate bundles, e.g. UI, 3x-int, broker-services. The latter is an abstraction of API usage also changed with 4.x: obtaining OSGi services and resource-provisioning code (image and font registries, and message bundles).

A couple concepts were mentioned without example that seem interesting but puzzling. The first was the notion of testing such a setup with all three targets: 3.x-, 3.x + compatibility layer-, and 4.x-based builds. The second was using 4.x annotations in 3.x code. I'm not sure how either would be done but they sound like they could be helpful. I can contact the presenter for more information if we need it.