We decided to use transactions from now to modify the model. See
http://www.eclipse.org/modeling/emf/?project=transaction#transaction for an overview. There are two reasons, why we want to use transactions:
1. The GMF Editor needs to do so.
2. It is likely that we will have concurrent threads modifying the model in the future, e.g. for an push update online mode.
The effect is that every modification on the model must be done inside of a transaction. Here is an example:
TransactionalEditingDomain domain = TransactionUtil.getEditingDomain(modelelement);
domain.getCommandStack().execute(new RecordingCommand(domain){
protected void doExecute() {
do sth with the model }
});
Don´t forget that your plugin needs a dependency to org.eclipse.emf.transaction.
If you are already using Commands, you don not have to change anything. This also applies for databindings.
If you were using a LabelProvider or an ContenProvider, replace them with TransactionProvider, e.g.:
new TransactionalAdapterFactoryContentProvider(TransactionalEditingDomain.Registry.INSTANCE.getEditingDomain
("org.unicase.EditingDomain"),new ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Registry.INSTANCE))
NOTE: In this example I choosed the second way to get the TransactionalEditingDomain using the Registry. This is useful if you do not have a reference to a part of the model, our Resource or our ResourceSet. If so you can use TransactionUtil.getEditingDomain(Eobject, Resource or ResourceSet);
For the TransactionalProvider you need to depend on org.eclipse.emf.transaction.ui
If you use modifications which are abstractable, it maybe useful to define you command as a class and reuse it.
If you do not use a transaction, you should get a "Write without transaction" Exception. This should make it very easy to find the places where the code needs to be refactored. I already did this for some components, it is applyable very fast!
4. Install Subclipse, Checkstyle and Findbugs (see