Eclipse Plugin Development SS 2012
In this lab-course we develop plug-ins for Eclipse in weekly iterations. Students get to know the plug-in architecture of Eclipse as well as core technologies such as RCP, SWT, EMF and GEF/GMF. Eclipse and its technologies are an emerging standard platform in many domains and delivers cutting edge technology. Further, the participants get in contact with the community of thousands Eclipse developer world-wide and learn how to communicate with them.
The plug-is developed in the lab-course are not toy examples but plug-ins for the UNICASE Eclipse client, the EMF Client Platform and the EMFStore. These projects are open-source and used by a broad community. So students work on a real problem in a real project environment, providing you with a unique learning experience. In fact they also have a possibility to become contributor or even committer on a real Eclipse Project.
Participants
|
Aumann |
Andreas Baya |
Stefan Bleibinhaus |
Johannes Faltermeier |
Andrei Haidu |
Sebastian Scheibner |
Tobias Verhoeven |
Supervisors
 |
Prof. Bernd Brügge, Ph.D. |
Contact
 |
Jonas Helming |  |
Maximilian Kögel |  |
Nitesh Narayan |  |
Yang Li |
 |
Helmut Naughton |
Projects
Jnect
Team: Andreas Bayha, Alexander Aumann, Johannes Faltermeier
The goal of this project was to update Jnect to work with the new Microsoft Kinect SDKs, first 1.0 then 1.5. Moreover three additional demonstration features were created. The first feature allows the user to record and replay their movement using EMFStore. For this task a new BodyProvider extension point was introduced to Jnect. Implementing plugins can provide Jnect with body-objects which will then be used. The second task was about creating a second GEF-Demo allowing users to manipulate parts of the diagram. The Shapes-Example featured in the GEF-SDK was adapted for this case so that users can move the shapes around using gestures. The last demo feature was about coming up with another application for speech control. Users are now able to control Eclipse by saying commands (which can be found under Window -> Preferences -> General -> Keys) out loud. Furthermore the Jnect project can now be built using Tycho.
Code Generation from UMLmodels 
Team: Sebastian Scheibner
The goal of this project was to allow code generation from within Unicase. By using a new simple wizard, UML models, which are created using Papyrus, can be easily converted to runnable code. As code generation backend the Eclipse plugin Acceleo is used. Acceleo enables code generation for many programming languages by using templates. So far code generation templates for Java and C++ have been created. Creating new templates is fairly straightforward, the existing templates can be used as a reference and there’s a tutorial on the web:
Dynamic EMF
Team: Tobias Verhoeven
The goal of this project was to allow the registration of new metamodels at the EMF-Store during runtime. Thus a new server-call which allows clients to register new EPackages at the EMF-Store was implemented. The call is accessible to administrators through the following use-case: "After login to a server an administrator can right-click on the server and choose "register EPackage” from the popup-menu. A new dialog is shown which allows the administrator to choose from the EPackages currently registered at the client. After clicking "OK" the selected EPackage is sent to the server.". The received EPackages are then registered at the EMF-Store and persisted by saving them as “.ecore”-files. The developed features are now part of the EMF-Store-Core.
EMFStore Branching
Team: Andreas Bayha, Alexander Aumann, Johannes Faltermeier
The EMFStore is a CVS/SVN like versioning system for EMF models. It has most recently been enhanced with branching capabilities in the context of a master’s thesis by Otto von Wesendonk. Just like in other versioning tools you may now commit your changes not only to the main trunk of history but to another branch, thus enabling parallel development on different states of the model which can later be merged again. The task for our team was to add a visual representation of these branches to the EMFStore History Browser View. We took the git branching graphs as a template and were even able to reuse parts of the code from the eclipse EGit/JGit projects for our branch graph. The outcome looks something like this:
More info on the new branching functionality can be obtained here: http://eclipsesource.com/blogs/2012/07/23/branching-support-for-the-emfstore-model-repository/
Issue Annotation Prototype
Team: Andrei Haidu
The goal of the project was to create an eclipse plugin with the help of which we can easily add new Issues to Unicase models, and review them. The project has not reached a final version. The current plugin code can be checked out from the following git repository git://github.com/haidu/issue-based-model-review-2012.git . The plugin is composed of an editor, which is opened by from the pop-up menu of a unicase project/composite (right click), and then clicking on the Show Models Editor, as shown below.
Afterwards, the editor is opened. Inside it has a section composed of a table and a toolbar. The table shows all the unicase models from the selected project/composition. And the toolbar has a button, which adds an Issue to the selected model from the table. Next to the section there is a text label with the name and the description of the selected items. A snippet of the editor can be seen below.
The important classes would be ModelViewEditor which extends the EditorPart abstract class. It takes as input an instance of ModelViewEditorInput which implements the IEditorInput interface. The table from the editor uses the ModelViewContentProvider and the ModelViewLabelProvider classes in order to get its input. The ViewModelsEditorHandler class is the handler for the opening the editor command. The extensions and the plugins files can be seen below. The extensions used, as seen are: a command which opens the editor, a pop-up menu with a call to the command and the editor.
MongoDB backend for EMFStore 
Team: Stefan Bleibinhaus, Tobias Verhoeven
The aim of the MongoDB-project was to allow EMFStore to use the document oriented database MongoDB as a storage provider. For this, we created a plugin, which can be found under github https://github.com/ExNexu/emfstore-mongodb/wiki as well as a set of patches, we committed to the EMFStore project via Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=380947. These first remove direct dependencies to actual files and instead replaces these with EMF-Resource dependent implementations. Secondly we enhanced the EMFStore with a new extension point, which can provide alternative storage options by providing new ResourceSets to the used ResourceSetRegistry. If no plugin is extending this extension point, EMFStore just uses the default XML storage. Our MongoDB-plugin extends this new “resourceset-extension-point” and supports the full feature set of the default storage option. This includes all CRUD operations as well as roundtrips to other clients. The plugin can be used for the client and/or the server-side of the EMFStore. Technically, our plugin relies heavily on the work of Bryan Hunt and his Mongo-EMF project, which can also be found at github https://github.com/BryanHunt/mongo-emf/wiki. His “project provides an EMF URI handler implementation that can persist EMF object instances to MongoDB”.
Virtual EMF
Team: Stefan Bleibinhaus, Sebastian Scheibner, Andrei Haidu
The aim for this project was to research if there is a way to virtually compose ecore metamodels, so that it behaves like any other ecore model. The need for this composition arrived because the Unicase models were all defined in a single ecore file. Therefore if a third party wanted to extend the model they had to modify the ecore file. Then every time the Unicase model changes, they have to rebase their own changes which could get complicated. The first step was to separate the Unicase models. Then a weaving model is created, which specifies the links between the two models. The steps creating a weaving model are the following: - Right click on the folder where you want to create the weaving model and select New → other → Model Weaver → Weaving Model - A wizard appears, where for “Weaving metamodel” we select the VirtualLinksMM.ecore file and click Next - Now we have to give a name for the new weaving model with extension .amw and click Next - Now we select the leftModel and click on “Edit selected model”, browse for the first metamodel we want to weave, then click OK and do the same for the rightModel We can see such a weaving model composition below.
The two models weaved are the left model task.ecore and right model util.ecore. Both separated from the Unicase model. In the middle are the weaved properties between the two files. Figure 1. After we created the weaving model with the help it and the ATL transformation file, we can compose the two ecore files. The steps we have to take are the following: - Open the Run Configurations dialog and create a new ATL Transformation - For “ATL Module” select the CompositionMetamodelBuilder.atl file - For Metamodels: - Ecore: uri:http://www.eclipse.org/emf/2002/Ecore - AMW: VirtualLinksMM.ecore - For LEFT_MM and RIGHT_MM select the leftModel and rightModel files you used for your weaving model - WEAVING_M is the .amw file you created - And in the end enter a suitable name for the Target Model, e.g. model1_model2_composition.ecore. All these setting can be observed in the following screenshot.
For composing more than two models at the moment we compose them two by two using the same steps described above. For future work it would be possible to create the ATL transformation file using a HOT (higher-order transformation) file that takes the weaving model (with all the models weaved) as input, and generate an ATL transformation as output.
Q7
Team: Andreas Bayha, Alexander Aumann, Johannes Faltermeier
Q7 is a tool for UI testing of eclipse based applications. It focuses on usability and intuitive handling and provides functionalities to easily record and manage Test Cases. For all test cases one can define Test Context, i.e. the circumstances like workspace content, preferences etc. by recording similarly as for Test Cases. Furthermore Test Cases may be reused and combined to Test Suits. The goal of our Task was to test EMFStore and the EMF Client Platform using Q7 by recording exemplary Test Cases and corresponding Test Contexts for all major functionalities of EMFStore. Unfortunately we were not able to successfully perform those tests, since there are serious problems with starting the EMF Client Platform from within Q7 (most of the views are not available). Since the Application Under Test (AUT) works fine when started regularly, it is unclear so far what could be the problem for this behaviour - an inadequacy of Q7 or some problem with the AUT. Another way of using Q7 by docking to an already running ("remote") instance of the AUT was successful and it appeared to be very convenient, help- and powerful for the EMF project. (Q7 Homepage: http://www.xored.com/products/q7/ )