The document discusses making EMF models and tools better citizens in OSGi environments. It identifies several issues that reduce OSGi's modularity advantages when using EMF, such as extensions forcing singleton plugins and EPackage registry keys not handling versions well. Solutions proposed include using OSGi services instead of extensions, a versioned EPackage registry, and reducing dependencies on EMF-generated classes by implementing model interfaces directly. This would make EMF models more reusable and portable across OSGi runtimes beyond just Equinox.

1. HTTP://RAONINERY.CGSOCIETY.ORG/GALLERY/853975/
(C) RAONI NERY (RAONINERY@GMAIL.COM)
3MF:
EMF TO THE INFINITY... AND BEYOND
ECON 2012 SPEAKER
MARCH 27TH, 2012 MIKAEL BARBERO – OBEO

3. POINTS OF INTEREST
Multiple Ecore Wipe out
Make EMF a
model versions in dependency from
better OSGi
the same OSGi Java interfaces to
citizen
container implementation
Work inspired from Alex Blewit and Neil Bartlett following posts [1, 2] and bugs [3, 4]
(1) http://njbartlett.name/2011/02/07/emf-in-osgi.html
(2) http://alblue.bandlem.com/2010/11/using-emf-for-osgi-service-creation.html
(3) https://bugs.eclipse.org/bugs/show_bug.cgi?id=329209
(4) https://bugs.eclipse.org/bugs/show_bug.cgi?id=328227

4. PARENTAL
ADVISORY
KEEP OUT
POSSIBILITY OF
BACKWARD INCOMPATIBILITY

5. USE CASE 1
ECORE MODEL V1 ECORE MODEL V2
Tool Vendor 1 Tool Vendor 2

6. WAIT, I CAN’T USE
TOOLS FROM THESE
TWO VENDORS AT
THE SAME TIME?
I don’t care if they are based on
some data model whose
different versions can not live
together.
HTTP://WWW.FLICKR.COM/PHOTOS/KALEXANDERSON/6237846841/

7. HTTP://WWW.FLICKR.COM/PHOTOS/RUSSMORRIS/181933880/
HTTP://WWW.FLICKR.COM/PHOTOS/ITSGREG/2634229136/ HTTP://WWW.FLICKR.COM/PHOTOS/RUSSMORRIS/181933880/
FIRST GUILTY:
ECLIPSE EXTENSIONS

8. FIRST GUILTY:
EXTENSIONS
OSGi is modular and dynamic by nature.
Extensions are reducing some of these
advantages by forcing plug-in to be singleton.
EMF uses extensions to contribute generated and
dynamic EPackages.

9. FIRST SOLUTION
Mimic GeneratedPackageRegistryReader and
DynamicPackageRegistryReader during activation
of model plug-ins.
Advantages: simple and mostly backward
compatible.
Drawbacks: plug-in must be activated to
contribute its model and some boilerplate code
needs to be written.

10. SECOND SOLUTION
Use OSGi (declarative) services.
Advantages: simple and mostly backward
compatible. Once defined as a service, any
requiring class can be made a component
requiring this service (DI).
Drawbacks: needs a ServiceTracker to track
services that can come and go anytime
EVEN BETTER OSGI R4.3: CREATE A CAPABILITY FOR EPACKAGES

11. HTTP://WWW.FLICKR.COM/PHOTOS/FIDDLEDYDEE/4349596304/
SECOND GUILTY
EPACKAGE.REGISTRY KEY

12. SECOND GUILTY:
REGISTRY KEYS
EPackage instances are identified by namespace
URI in the Registry.
Best practice (workaround?) today is to include
version into namespace URI.
It should be a tuple (URI, Version)

13. SOLUTION
Need a specific EPackage.Registry
implementation that handle versions
public interface VersionedRegistry extends EPackage.Registry {
EPackage getEPackage(String nsURI, String version);
EFactory getEFactory(String nsURI, String version);
}
Contributed through
package_registry_implementation extension point.
Version can be valued from a property of service
or from version of contributing bundle (or from
capability?)

14. USE CASE 2
« If the interfaces can be kept "clean", i.e.
without any references to EMF-generated
implementation classes or to EMF itself, then the
APIs can be used standalone, for example in a
memory constrained environment. In this scenario,
normal hand-coded implementation classes could
be used. »
Neil Bartlett
https://bugs.eclipse.org/bugs/show_bug.cgi?id=329209

15. HTTP://WWW.FLICKR.COM/PHOTOS/DCJOHN/12852539/
GUILTY:
EPACKAGE.EINSTANCE

17. aces
Interf
EMF
YOUR MODEL

18. aces
Interf
EObject EPackage EFactory
EMF
YOUR MODEL

19. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL

20. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EMF
YOUR MODEL

21. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EObjectImpl EPackageImpl EFactoryImpl
EMF
YOUR MODEL

22. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EObjectImpl EPackageImpl EFactoryImpl
EMF
FooImpl BarPackageImpl BarFactoryImpl
YOUR MODEL

23. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EObjectImpl EPackageImpl EFactoryImpl
EMF
FooImpl BarPackageImpl BarFactoryImpl
YOUR MODEL

24. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EObjectImpl EPackageImpl EFactoryImpl
EMF
FooImpl BarPackageImpl BarFactoryImpl
YOUR MODEL

25. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EObjectImpl EPackageImpl EFactoryImpl
EMF
FooImpl BarPackageImpl BarFactoryImpl
YOUR MODEL

26. aces
Interf
EObject EPackage EFactory
EMF
Foo BarPackage BarFactory
YOUR MODEL
Impl
EObjectImpl EPackageImpl EFactoryImpl
EMF
FooImpl BarPackageImpl BarFactoryImpl
YOUR MODEL

27. BENEFITS
Make generation gap pattern very natural and
easy.
Change from plain EMF objects to CDO native
objects.

28. SOLUTION
EObjectImpl
FooImpl BarPackageImpl
Add a method to (Internal)EObject
abstract EPackage ePackage();
Can be done in an extending interface
implemented by only newly generated models

29. SOLUTION
EObjectImpl
FooImpl BarPackageImpl
Field in Field in
EPropertiesHolder XXXObjectImpl
Access to
EPackage.Registry.INSTANCE
In all cases, it requires to give its defining EPackage to the
EObject’s constructor, and then to modify XXXFactoryImpl

30. SOLUTION
Some adapter factories need to be modified too
(AdapterFactory for models)
Need to introduce a new interface extending
AdapterFactory
public interface ModelAdapterFactory<P extends EPackage, F extends EFactory>
extends AdapterFactory {
P getEPackage();
F getEFactory();
}

31. SOLUTION
public interface ModelAdapterFactory<P extends EPackage, F extends EFactory>
extends AdapterFactory {
P getEPackage();
F getEFactory();
}
XXXItemProviderAdapterFactory is also
implementing it
XXXItemProviders are taking this interface as
argument to their constructor instead of simple
AdapterFactory.

32. BIND IT ALL
This solution perfectly fits
with registration of
EPackages as OSGi
(declarative) services

33. USE CASE 3
« I want to use EMF models on another OSGi
runtime than Equinox »

34. ECLIPSE RICH CLIENT ECLIPSE
WORKBENCH PLATFORM HEADLESS
IDE RCP EQUINOX
STANDALONE ECLIPSE RICH GOOGLE WEB
AJAX PLATFORM TOOLKIT
JAVA RUNTIME RAP GWT
SUPPORTED PLATFORMS
RAP AND GWT SINCE EMF 2.6

35. What about other OSGi
runtimes?
When running in an OSGi container,
EMF explicitly requires the following
8 bundles:
org.eclipse.core.runtime
org.eclipse.equinox.common
org.eclipse.core.jobs
org.eclipse.equinox.registry
org.eclipse.equinox.preferences
org.eclipse.core.contenttype
org.eclipse.equinox.app
org.eclipse.osgi
HTTP://NJBARTLETT.NAME/2011/02/07/EMF-IN-OSGI.HTML

36. SOLUTION 1 & 2
(Repackage EMF bundles)
Big refactoring to separate
Eclipse/Equinox related bits
from OSGi related bits
Use import-package instead
or require-bundle

37. SOLUTION 3
There are some less radical changes that can be
done in a backward compatible fashion, but
Introduces even more graceful handling of target
running platform into the runtime
Ex: rewriting EMFPlugin.IS_ECLIPSE_RUNNING
in a similar way to
IS_RESOURCE_BUNDLE_AVAILABLE in the
term of a new EMFPlugin.IS_OSGI_RUNNING.

38. CONCLUSION
EMF is a great piece of engineering
OSGi is a great piece of engineering too
3MF is an experimentation to make EMF mimic /
use some of the best qualities of OSGi (modularity,
dynamicity)
With these, EMF would reach the infinity... and
beyond!

39. CONCLUSION
EMF is a great piece of engineering
OSGi is a great piece of engineering too
3MF is an experimentation to make EMF mimic /
use some of the best qualities of OSGi (modularity,
dynamicity)
With these, EMF would reach the infinity... and
beyond!

40. HTTPS://GITHUB.COM/MBARBERO/EMF/TREE/3MF
HTTP://WWW.SLIDESHARE.NET/MIKAELBARBERO/
HTTP://WWW.FLICKR.COM/PHOTOS/B-LOVE/5032931614/
MIKAEL.BARBERO@OBEO.FR
HTTP://WWW.OBEO.FR