Pitfalls running E11 as embedded SWT browser in Eclipse

Recently I implemented a preview view for an Xtext DSL that uses an embedded jetty and renders a JSF screen without deployment. To make bidirectional navigation possible from Xtext to JSF and the other way round, I decided to use websockets. That worked pretty well since I am working on a mac, but when the customer tried to used it the application did not work at all because of Windows and IE11.

First of all there is a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=404543 that runs IE in compatibility mode to IE9 that does not have websockets integrated. :-( After switching to Luna 4.4.1 it worked until the next bomb exploded. After exactly 6 reloads the browser raised a Security Error when someone starts to establish a websocket connection... That is because IE11 and below do not really close a websocket implicitly when a page is reloaded or closed as it happens in "modern" browsers automatically. The number of connections that are allowed is hard coded deep inside the registry. BTW I hate that registry stuff sooooo much.... After closing the websockets explicitly everything works as expected even within Windows 8.1 and IE11. The whole story took me 2 full days ... Why the hell does Microsoft always do things different in their Internet Explorer. Luckily I do not have to work with that environment sooo often.

Integration of Xtext with Flux

Flux is a very new project at Eclipse and we wanted to find out what it needs to integrate Xtext with this cool new technology. In the video you'll see syntax highlighting, content assist, validation and navigation in action.

Xtext in the web

Based on Orion & Xtext we are now able to provide rich-featured DSL editors for the browser. The editors not only support the basic features known from Orion's JavaScript editor but also come with some additional goodies :

•     Lexical and semantic highlighting
•     ContentAssist
•     Hover
•     Formatting
•     Organize Imports
•     Validation

We were even able to integrate fun stuff, like compiling & executing Xtend code on the fly. I've recorded a screencast to show off what's already working.
Please contact us if you are interested in this.



Sponsored by

Really small and easy to use EMF Generator

Today I started a really small and easy to use project to generate the EMF Code out of a GenModel. https://github.com/holgerschill/EMF-Generator

There are several different implementations to generate Code out of a EMF GenModel out there. Some of them are easy to use and others not but in all cases you have to use a headless eclipse or workflow written in some other framework. Running EMF generator on a buildserver is also possible with EMF2Java task so why do we need another tools for that.

The answer is easy. This generator doesn't deal with a headless eclipse. There is no need to have an eclipse installed. This generator doesn't use ANT or what else. It is really lightweight and only two parameters are needed.

# java -jar generator.jar /PATH/TO/WORKSPACE URI_TO_GENMODEL

That's all. You could even use a platform:/resource URI because the platformURI mapping is done for you.

oAW WorkflowComponent for EMF-Compare in no time

EMF-Compare is a really cool framework to identify differences between EMF based models in no time. Together with two collegues I am currently writing an article to show the main facts and how the results could be used in a MDSD-approach. In our first step we created a class to trigger the Match- and DiffService to have a Diff-Model as a result. After having that, we wanted to use the generator-framework openArchitectureWare to generate a more readable report of the differences. For that reason we used the serialized diffmodel as input for the generator. After playing around with that, we saw that it is annoying to have two different steps. One for the creating the diffmodel and one for generating the report.
The first thing you might think of when you have this use case is creating an ant-script. In our case we wanted to integrate the creating of the diffmodel in the generator-workflow. For that reason we implemented an custom workflow-component.
I was wondering how fast an easy it could be to do that. You only have to extend the Class AbstractEmfWorkflowComponent and fill the method invoke(WorkflowContext ctx, ProgressMonitor monitor,Issues issues). By doing that you could reuse the already done configurations from the workflow. For example the loading of the necessary metamodels and so on .



In our special case we wanted to have special parameters. To do that you only have to have getters and setters for that stuff. After implementing the method checkConfiguration(Issues issues) it was possible to check it the necessary parameters have been passed to the Component.


The next thing that was really cool is that we do not have to persist the diffmodel any more. We only have to pass the result to the modelslot of the Workflow. By doing that the diffmodel could be used by following Components within the Workflow.


As you can see from the screenshot of the Workflow the new Component is now well integrated and no extra step is necessary.

Why it could be a problem to have a copy of a metamodel

Some days ago I had a strange problem by using the diffmodel of EMF-Compare. Together with a college I tried to generate a more readable format out of a diffmodel.

A diffmodel shows the differences between to given instances of the same metamodel. For that reason it has dependencies to the instances and their metamodel.

In our scenario we copied the diff.ecore in our project in the same folder as our metamodel. Just to see how it looks like and to use it in our approache of loading the diffmodel in a oAW-generator-workflow.

For testing we created two simple instances of our metamodel and added a new object to one of them. In this case the diffmodel holds a reference to the new created object and the parent object.

In this scenario you will have no problems in reading the given diffmodel. But when you change a value of an attribute of a existing object in one of the instances it will cause a problem. The diffmodel will have a reference to the feature of the metaobject of this object.

In this case EMF was not able to resolve the type of the feature which is a reference to a metamodelobject of ecore.ecore. Normaly this should not be a problem.
After some time of playing around with different scenarios of we found out that the diff.ecore metamodel of the diffmodel uses different ways of pointing to the ecore metamodel.

As you can see from the screenshot the elements of the ecore metamodel is sometimes referenced via NsUri and sometimes via platform:/plugin.
This will cause a problem if you have the diff.ecore file in a different location as delivered with the emf-compare plugin. Only for testing we replaced all references to platform:/plugin with the NsUri and we saw that it worked. I don not know why this has been done, but for maintenace it it important not to use your one custom variant of the metamodel.
For that reason we directly referenced to the generated code within the emf-compare plugin via org.eclipse.emf.compare.diff.metamodel.DiffPackage. After that we were finally able to read any diffmodel instance.

Finally

Puh. I finally decided to start a blog. From now on I will do my best to publish intresting thing around Eclipse and MDSD. I am looking forward to discussions with other people that will read this blog.