EMF Dos and Don´ts #5

EMF is a very powerful framework and with power comes…responsibility. You can achieve great things with a minimum of effort using EMF, but if something goes wrong, you can also spend hours trying to find out why. This blog post is part of a series on things you should do and things you should not do when using EMF. You can use the link to the series pilot to navigate to the start and the link below to navigate to the next blog once it is published.

EMF Dos #5: Use multiple ECores, not Sub-packages

If you have defined many EClasses, an Ecore model can quickly get messy. Sub-packages are indeed a good way to keep your model clean and well-sorted. However, there is one drawback – sub-packages are and have been a source of bugs and problems. Developers of EMF-based frameworks sometimes forget to correctly address the special case of sub-packages. Furthermore, sub-packages are not even supported in XCore. XCore is an emerging  programming language used to express the structural properties of a model similar to Ecore in a textual syntax.  XCore also allows users to express the dynamic behavior of an operation of an EClass with an XBase-based expression language. This is what Ed Merks says about whether XCore supports sub-packages (or will support them in the future):

“No, they’re not supported and I definitely don’t plan to support them.  They’re evil.  So many headaches just so an EPackage can have getESubPackages and getESuperPackage.”

If you ask Ed Merks  about what he would change in EMF if he could without breaking compatibility, sub-packages take a prominent place on his list.

Fortunately, there is a simple way to avoid problems with sub-packages. Just define another Ecore with the content of the sub-package. By setting the prefix accordingly, the corresponding Java classes will be generated into a sub-package of the intended parent package. They all could even be generated into one plugin potentially. Stay tuned for more Dos and Don’ts in my next blog!