Jump to: navigation, search

Difference between revisions of "Mylyn/Context/Modeling Bridge"

(Developers)
Line 27: Line 27:
 
=Developers=
 
=Developers=
  
We've tried to design the modeling bridge so that it is easy to integrate your own bridge. 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 -- let us know if you'd like to participate in or support that effort!) Please let us know if you have any difficulties or improvements for the below steps.
+
We've tried to design the modeling bridge so that it is easy to make your own GMF and other EMF-based editors and views Mylyn savvy. 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 -- let us know if you'd like to participate in or support that effort!) Please let us know if you have any difficulties or improvements for the below steps.
  
 
===Concepts===
 
===Concepts===
Line 57: Line 57:
 
;FooUiBridge (Copied from Uml2UiBridge)
 
;FooUiBridge (Copied from Uml2UiBridge)
 
: Define diagrams and views which should be managed by Mylyn. See DiagramUiBridge for details.
 
: Define diagrams and views which should be managed by Mylyn. See DiagramUiBridge for details.
 
  
 
= Project Details =
 
= Project Details =

Revision as of 14:32, 8 September 2011

EcoreMylyn.png
Mylyn for Modeling brings the productivity, integration and traceability benefits of Mylyn to Eclipse Modeling. It provides a focused mode for diagrams that shows only the elements related to the task-at-hand, dramatically reducing information overload for engineers working on large models. In addition, the task-focused interface extensions provide Mylyn’s one-click multitasking facilities for working with models, ensuring that developers can instantly recover from interruptions, and share model-specific expertise, when working with models in addition to what Mylyn already provides for engineers working with source code.

This work is developed by Tasktop Technologies and sponsored by Ericsson in the context of the Modeling Platform Industrial Working Group

Status

There are a few remaining usability related tasks, but basic implementation is complete. Currently, Mylyn for Modeling supports EcoreTools diagrams and Project Manager integration as well as Papyrus UML2 class diagrams. The supporting modeling bridge is designed to be relatively easy to extend to support arbitrary GMF supported diagram editor.

There are a number of additional extensions contemplated, including support for EMF Tree Editors.

Schedule (dates tentative)

We're hoping for an 0.9.0 release sometime in September.

Users

Installation

Currently, the features can be installed from:

http://ci.mylyn.org/job/mylyn-incubator-modeling-bridge/lastSuccessfulBuild/artifact/org.eclipse.mylyn.incubator-site/target/site/

Select Mylyn for EMF and GMF, along with Ecore Tools for Ecore and Ecore Diagram support and/or Papyrus for UML Class diagram support. (Mylyn for modeling has the minimal dependencies on those tools, so you should probably install the target tools separately if you don't already have them.) The tools should work with the Indigo Ecore Tools and Papyrus modeling components.

Please note that the project has not yet been contributed to Eclipse and so has not passed formal review. We don't anticipate any issues with this.

Developers

We've tried to design the modeling bridge so that it is easy to make your own GMF and other EMF-based editors and views Mylyn savvy. 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 -- let us know if you'd like to participate in or support that effort!) Please let us know if you have any difficulties or improvements for the below steps.

Concepts

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.

Integrating Mylyn for Modeling with custom GMF editors

Recipe

Copy Existing Project

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.eclipse.mylyn.internal.modeling.foo.FooDiagramDecoratorProvider">
  • etc..

Define Model Specific Behavior

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

FooStructureBridge (Copied from Uml2StructureBridge)
Define domain objects which should be managed by Mylyn. See DomainModelContextStructureBridge for details.
FooUiBridge (Copied from Uml2UiBridge)
Define diagrams and views which should be managed by Mylyn. See DiagramUiBridge for details.

Project Details

Bugzilla

Release bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=352032

All related bugs:

https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bmodeling%5D;resolution=---;query_format=advanced;short_desc_type=allwordssubstr;component=Experiments;product=Mylyn%20Incubator

Bug Reports

  • Product: Mylyn Incubator
  • Component: Experiments
  • Deescription: Include "[modeling]" as keyword.

Git Repos

URL: git@github.com:MilesParker/mylyn.incubator.git

This is a temporary home only, we hope to contribute it to Eclipse git soon.

Projects: org.eclipse.mylyn.modeling.*

Communication

Please use: mylyn-incubator-dev. Discussion also on EMFT-dev.

Related Documents

  • Blog Post by Miles Parker on the current effort.
  • Blog post by David Green, Tasktop’s VP of Engineering, for model-driven development diagrams based on a model similar to, but not based on, EMF.
  • Mik Kersten’s PhD thesis on Mylyn. See especially Section 5.4.1.

Team

  • Miles Parker for Tasktop
  • Benjamin Muskalla Tasktop

Original Proposal

Context Bridge for EMF Models

Model context.png

In order to bring the productivity benefits of the task-focused interface to engineers using Eclipse-based modeling technologies, Tasktop will create a “Context Bridge” for EMF-based models and diagram editors. The result of this will be a focused mode for diagrams that shows only the elements related to the task-at-hand, dramatically reducing information overload for engineers working on large models. In addition, the task-focused interface extensions will provide Mylyn’s one-click multitasking facilities for working with models, ensuring that engineers can instantly recover from interruptions, and share model-specific expertise, when working with models in addition to what Mylyn already provides for engineers working with source code.

This feature is a new technology, that to date has only been discussed in Kersten’s PhD thesis and implemented by David Green, Tasktop’s VP of Engineering, for model-driven development diagrams based on a model similar to, but not based on, EMF.[1]

High-Level Tasks

EMF Context Bridge

Integration between the EMF Ecore model with the Mylyn Context degree-of-interest model.

  • EMF-1: identity of Ecore elements is integrated with task context
  • EMF-2: relationships and containment are mapped to the degree-of-interest graph
  • EMF-3: degree-of-interest model elements updated on refactoring of model, for active task
  • EMF-4: contexts with refactored model elements are updated when loaded, eg, using refactoring history

Model project explorer.png


GEF Diagram Focusing

Support for user interface focusing and one-click multitasking facilities for models and diagrams[2] .

  • FOCUS-1: creation of figure filter, highlighter and layout for focused diagrams
  • FOCUS-2: degree-of-interest based view updated and model change notification integration
  • FOCUS-3: Ecore model focusing for Common Navigators
  • FOCUS-4: APIs for GEF figure focusing for downstream editors
  • FOCUS-5: usage tracking for Ecore model and GEF diagram editing and navigation
  • FOCUS-6: editor mementos are restored on task-reactivation
  • FOCUS-7: quick/in-place view of model elements in context
  • FOCUS-8: focus support for EMF models in GMF for UML models in Papyrus.


  1. http://greensopinion.blogspot.com/2008/12/mylyn-context-driven-domain-diagram.html.
  2. Degree-of-interest diagram highlighting can be applied to arbitrary diagrams, while degree-of-interest filtering only applies to diagrams where positioning does not have a semantic relevance (eg, works for UML class diagrams, but not for a pipe-and-filter diagram without additional support for displaying elided elements). For more information see 5.4.1 and related sections of Kersten’s PhD thesis: http://www.tasktop.com/docs/publications/2007-01-mik-thesis.pdf