Mylyn + Your GMF Models = Love?

As a quick follow-up to my post yesterday, here's an overview on how to integrate Mylyn with your own GMF editors. We'll be maintaining this on the Mylyn for Modeling wiki page but I wanted to share it with you here as well so you can see how easy it is to get the Mylyn love into your diagrams.

There are a number of artifacts to take care of but much of it is boiler-plate. (It would be straightforward to support this with a simple meta-model and code generation, hint, hint..) Please let us know if you have any difficulties or improvements for the below steps.

The Basic Idea

Users aren't interested in the diagram objects, they're really interested in the underlying domain or model objects. In the Mylyn Java integration, for example, Java classes and methods are tracked, and then revealed in various ways in different editors. So for an EcoreTools model for example, we don't want or need to keep track of the diagram Node objects or any other reference in the various foo.gmf.. files for, we want the domain object itself, e.g. EClass, EPackage, etc.. in the corresponding foo.ecore resource. What we need to do is to define what the user might be interested (or not interested) in and then map that to the diagram editors and other editor types.

Your Turn!

The best thing to do is just start with one of the two existing projects. We'd recommend org.eclipse.mylyn.modeling.papyrus.ui. org.eclipse.mylyn.modeling.ecoretools.ui will give you some ideas about how to work with a more complex scenario.

Refactor Artifacts

Rename files and other artifacts with the appropriate names. For example in your GMF "Foo" Diagram tool:

• Uml2DiagramDecoratorProvider -> FooDiagramDecoratorProvider
• In Plugin.xml

  <decoratorProvider class="org.eclipse.mylyn.internal.modeling.papyrus.Uml2DiagramDecoratorProvider">

  Becomes:

  <decoratorProvider class="org.you.foo.FooDiagramDecoratorProvider">

• etc..

Here's where the non-boiler plate stuff is.

Structure Bridge

In FooStructureBridge, you'll define domain objects which should be managed by Mylyn. This is how it is implemented in UML2StructureBridge:

@Override
 public Class<?> getDomainBaseNodeClass() {
  return Element.class;
 }

 @Override
 public Class<?>[] getDomainNodeClasses() {
  return new Class[] { Classifier.class };
 }

 @Override
 public Class<?> getDomainBaseEdgeClass() {
  return Relation.class;
 }

 @Override
 public Class<?>[] getDomainEdgeClasses() {
  return new Class[] { Relation.class };
 }

See DomainModelContextStructureBridge for API details .

Diagram Bridge

In FooUiBridge, you'll define diagrams and views which should be managed by Mylyn. In UML2UiBridge, the important bits are:

@Override
 public boolean acceptsPart(IWorkbenchPart part) {
  return part instanceof PapyrusMultiDiagramEditor;
 }

 @Override
 public boolean acceptsViewObject(Object domainObject, Object part) {
  if (domainObject instanceof Classifier) {
   return part instanceof ClassEditPart;
  }
  if (domainObject instanceof Package) {
   return part instanceof PackageEditPart;
  }
  //Edges
  if (domainObject instanceof Relationship) {
   return part instanceof ConnectionNodeEditPart;
  }
  return false;
 }

See DiagramUiBridge for details.

Simple, Eh? Just a lot of search and replace. If you want to contribute or help with code generation for this, that would be a really nice...

So try it out and please let us know how it goes or if you run into trouble. It would be awesome to see more complex examples of Mylyn based GMF model editors, so please experiment and share your examples! And don't forget to check the Wiki Page as that's where the up to date documentation will be.