Currently I’m working at one of our customers where PVCS is used as VCS. The MDSD toolchain that I’m developing here bases on GMF, Xtext, EMF, and – of course – Eclipse.

As our customer’s models are quite big they’re spread across several files. This enables them to work as a team on several parts of a model at the same time. Now, PVCS is working by switching read-only states of files depending if they are checked out or not. In the context of this environment this means that usually large parts of the model are read only. The GMF editor built is using a shared editing domain to allow users to open several diagram editors at the same time to work on different parts of the model.

Unfortunately, with it’s defaults the generated GMF diagram editor has a hard time getting along with a model consisting of many read only files and a few writable ones. Trying to save a diagram results in checking all resources in the shared resource set. Any read only resource will be collected and listed in a dialog asking the user to make it writable regardless if it wasn’t affected by changes. Of course, our customer doesn’t want to make the unsed files writable, but having to click “No” on that dialog all the time is anoying. Even worse is, that choosing “No” will not save the modified model files but only the diagram file – if it was changed.

With this already being not amusing at all to complete the worst case scenario, GMF marks the editor as clean somehow although resources in the resource set are dirty and is unusable afterwards. Users are forced to close the editor and re-open the diagram file to continue editing.

Well, I wouldn’t write that post if I had not found a quite simple solution for this. I changed two of GMF’s generator templates to add and modify the default generated behavior. The templates in question are: DocumentProvider.xpt and Editor.xpt. The changes done add two features. First, I disabled that dialog about making unaffected read only files writable. Second, I prevented the diagram editor from switching to an unusable state.

No more make-writable dialog

Here’s how I got rid of the annoying make-everything-writable dialog.
DocumentProvider.xpt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

«AROUND doValidateState FOR gmfgen::GenDiagram-»
	«EXPAND xpt::Common::generatedMemberComment»
protected void doValidateState(Object element, Object computationContext) throws org.eclipse.core.runtime.CoreException {
	ResourceSetInfo info = getResourceSetInfo(element);
	// ITEMIS CHANGE: only enter if branch when not saving
	if (info != null && !isValidateStateForSave()) {
	// ITEMIS CHANGE END
		java.util.Collection/**/ files2Validate = new java.util.ArrayList/**/();
		for (java.util.Iterator/**/ it = info.getLoadedResourcesIterator(); it.hasNext();) {
			org.eclipse.emf.ecore.resource.Resource nextResource = (org.eclipse.emf.ecore.resource.Resource) it.next();
			org.eclipse.core.resources.IFile file = org.eclipse.emf.workspace.util.WorkspaceSynchronizer.getFile(nextResource);
			if (file != null && file.isReadOnly()) {
				files2Validate.add(file);
			}
		}
		org.eclipse.core.resources.ResourcesPlugin.getWorkspace().validateEdit((org.eclipse.core.resources.IFile[]) files2Validate.toArray(new org.eclipse.core.resources.IFile[files2Validate.size()]), computationContext);
	}
 
	super.doValidateState(element, computationContext);
}
«ENDAROUND»
 
«AROUND additions FOR gmfgen::GenDiagram-»
	// ITEMIS CHANGE: additional members to flag validateState to exclude read-only resources while saving
	«EXPAND xpt::Common::generatedMemberComment»
	private boolean validateStateForSave = false;
 
	«EXPAND xpt::Common::generatedMemberComment»
	public void setValidateStateForSave(boolean value) {
		validateStateForSave = value;
	}
 
	«EXPAND xpt::Common::generatedMemberComment»
	public boolean isValidateStateForSave() {
		return validateStateForSave;
	}
	// ITEMIS CHANGE END
«ENDAROUND»

The above changes introduce a validateStateForSave-flag to the generated document provider. This flag needs to be toggled in the generated diagram editor when running the doSave() method. The following template change adds this behavior.
Editor.xpt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

«AROUND additions FOR gmfgen::GenEditorView-»
// ITEMIS CHANGE: flag validate state to exclude read-only resources
«EXPAND xpt::Common::generatedMemberComment»
@Override
public void doSave(org.eclipse.core.runtime.IProgressMonitor progressMonitor) {
	org.eclipse.gmf.runtime.diagram.ui.resources.editor.document.IDocumentProvider p = getDocumentProvider();
	if (p instanceof bellis.diagram.classes.part.ClassesDocumentProvider) {
		((bellis.diagram.classes.part.ClassesDocumentProvider) p).setValidateStateForSave(true);
	}
	super.doSave(progressMonitor);
	if (p instanceof bellis.diagram.classes.part.ClassesDocumentProvider) {
		((bellis.diagram.classes.part.ClassesDocumentProvider) p).setValidateStateForSave(false);
	}
}
// ITEMIS CHANGE END
«ENDAROUND»

Keep GMF editor usable

As I said before, the annoying dialog is just one side of the read only challange. The other is to prevent the GMF editor from switching into an unusable state. To do so, I figured gutting the document provider’s updateCache() method is probably the best way to go.
DocumentProvider.xpt:

1
2
3
4
5
6
7
8
9
10
11
12
13

«AROUND updateCache FOR gmfgen::GenDiagram-»
	«EXPAND xpt::Common::generatedMemberComment»
protected void updateCache(Object element) throws org.eclipse.core.runtime.CoreException {
	ResourceSetInfo info = getResourceSetInfo(element);
	if (info != null) {
		// ITEMIS CHANGE: prevent GMF-Editor from turning unusable after saving
		info.setReadOnly(false);
		info.setModifiable(true);
		// ITEMIS CHANGE END
		return;
	}
}
«ENDAROUND»

These changes made me smile again about the diagram editor that’s generated now.