Known problems

EMF Package registration and XCore

Normally, the plug-in that defines the Ecore models would declare extensions for extension point

org.eclipse.emf.ecore.dynamic_package

This, however, doesn't seem to work for xcore model files.

The current workaround is that the activator of the core plug-in registers the packages for the two models in its start routine:

private void registerEmfPackages() {
    EPackage.Registry.INSTANCE.put(ChecklistcfgPackage.eNS_URI, ChecklistcfgPackage.eINSTANCE);
    EPackage.Registry.INSTANCE.put(ProtocolPackage.eNS_URI, ProtocolPackage.eINSTANCE);
}

The registration-by-impl works fine as long the core plug-in is running. However, we get into problems if the application starts into an open editor. Since the actual model classes are loaded after EMF has scanned the files (and the reader is in the i/o plug-in, not the core plug-in), the core plug-in isn't running when the XMI is read, which results an error message

Package with URI '*' not found The current workaround for this is that the UI plug-in's activator calls the core plug-ins' activator which in return causes the core plug-in to start.

There must be another way to solve the registration problem.

Undo/Redo

See #2. Remove or update this after issue #2 is closed and problem has been solved The undo/redo feature appears to require a save to the EMF resource before the command stack gets updated to be enabled. Maybe this has to do with using a TransactionalEditingDomain instead of a "normal" EditingDomain. I can't say, yet. Maybe, this has to do with saving options for a ResourceSet.

The general setup, however, seems to be very simple: Just define a "contributor" to the editor extension and let the "contributor" class derive from EditingDomainActionBarContributor. The editor then has to implement interface IEditingDomainProvider, which defines only one method to get the EditingDomain. That seems to cover it. Well, apart from the problem described above.