Friday, December 5, 2014
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.
Monday, April 7, 2014
Tuesday, November 20, 2012
- Lexical and semantic highlighting
- Organize Imports
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.
Monday, March 19, 2012
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.
Friday, April 3, 2009
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.
Monday, February 9, 2009
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.