Attending Eclipse Summit Europe 2009 once again felt like a big family meeting. It is always a pleasure to meet people you usually only correspond with electronically in person. The organization was once again almost perfect and the food excellent. Thanks a lot to the organizers and sponsors!
We had a very productive project meeting for the EMF Index project, clarifying a lot of critical points and further aligning the efforts and requirements of the involved parties.
Markus, Sebastian, Karsten and me were impressed by the large number of about 50 participants in our workshop on Domain-specific Languages with Eclipse Modeling. The slides are now online at slideshare, just in case you're interested. With such an audience it was of course a little bit difficult to make it a real hands-on experience, but I think we at least managed to leave a good impression on the presented toolchain.
Jos's and my talk on Combining text and graphics in modeling tools was also well attended, and from the quality of questions that were asked I guess our message has been understood. The slides are also available at slideshare.
Apart from a number of really impressive talks, the thing that most impressed me was SAP's graphical editing framework. Instead of using a code-generation approach it rather focusses on an provider-based Java API. They are currently in the process of adapting it to EMF and their plan is to make it open source. I hope they really do, because it seems to have the potential of greatly reducing the complexity of creating graphical editors.
Friday, October 30, 2009
Sunday, October 25, 2009
GMFTools Part 2: Sharing an EditingDomain
In this blog, I will elaborate on how GMFTools facilitates to share the same instance of an EditingDomain across multiple diagram editors.
What is an EditingDomain?
In GMF, each diagram editor works on its own instance of a so called TransactionalEditingDomain. TransactionalEditingDomain is a concept from EMF Transaction. In GMF, it contains an EMF ResourceSet holding the diagram model, its semantic model and all referenced models as well as a command stack for undo/redo support. In addition, each editor registers a WorkspaceSynchronizer to its resource files, making sure external changes are synchronized with the editor's content.
Why share the EditingDomain?
In the default setup, problems occur if two editors operate on the same resources: If both editors change the same resource, saving one will overwrite the changes of the other. This situation already happens when you're using the Related Diagrams feature in the gmfmap model: On double click, it will open a new diagram that is saved in the same resource but in a different editing domain. As the original editor is still open, conflicts can arise quickly.
Another reason for sharing the editing domain is to save memory and performance, especially if you're working on big models with a couple of editors.
In many cases you might want to see changes immediately in all editors without having to save first, e.g. when your editors show different parts or aspects of the same model. GMF has already built-in support for that as it uses EMF's notification mechanism to synchronize the notation (diagram) model with the semantic model.
Consequences of sharing an EditingDomain
Sharing the editing domain across several editors has a number of consequences
The solution in GMFTools is based on a WiKi page of GMF and a couple of newsgroup entries combined with our own experiences. It has been recently refactored to reenable the WorkspaceSynchronizer.
It comes in a number of aspectual template changes for the GMF code generator, an additional runtime plug-in and tool support for fixing the type registry, such that it is rather easy to consume even if you're not too familiar with the GMF runtime. Note that so far we have only been using it to generate plain diagram plug-ins, i.e. not for GMF's RCP generator.
The major changes are
What is an EditingDomain?
In GMF, each diagram editor works on its own instance of a so called TransactionalEditingDomain. TransactionalEditingDomain is a concept from EMF Transaction. In GMF, it contains an EMF ResourceSet holding the diagram model, its semantic model and all referenced models as well as a command stack for undo/redo support. In addition, each editor registers a WorkspaceSynchronizer to its resource files, making sure external changes are synchronized with the editor's content.
Why share the EditingDomain?
In the default setup, problems occur if two editors operate on the same resources: If both editors change the same resource, saving one will overwrite the changes of the other. This situation already happens when you're using the Related Diagrams feature in the gmfmap model: On double click, it will open a new diagram that is saved in the same resource but in a different editing domain. As the original editor is still open, conflicts can arise quickly.
Another reason for sharing the editing domain is to save memory and performance, especially if you're working on big models with a couple of editors.
In many cases you might want to see changes immediately in all editors without having to save first, e.g. when your editors show different parts or aspects of the same model. GMF has already built-in support for that as it uses EMF's notification mechanism to synchronize the notation (diagram) model with the semantic model.
Consequences of sharing an EditingDomain
Sharing the editing domain across several editors has a number of consequences
- The editors will also share the same command stack. Undo/redo becomes a global operation and can therefore affect other editors than the currently active one.
- For reasons of simplicity, all editors should be saved synchronously, and they will all be either dirty or clean at the same time.
- You should no longer dispose the editing domain when closing an editor. That means, to avoid memory leaks you need strategy for unloading unneeded resources.
- The command stack will keep references to unloaded model elements, too, so you might want to have an garbage collecting strategy here as well or at least keep the command history short.
The solution in GMFTools is based on a WiKi page of GMF and a couple of newsgroup entries combined with our own experiences. It has been recently refactored to reenable the WorkspaceSynchronizer.
It comes in a number of aspectual template changes for the GMF code generator, an additional runtime plug-in and tool support for fixing the type registry, such that it is rather easy to consume even if you're not too familiar with the GMF runtime. Note that so far we have only been using it to generate plain diagram plug-ins, i.e. not for GMF's RCP generator.
The major changes are
- Redirect all creation statements of an editing domain to a new utility class and the dispose statements to an unloading tool.
- Make sure to use consistent element types.
- The common behavior of all XXDocumentProvider.ResourceSetInfo has been extracted to avoid synchronization feedback loops.
Friday, October 9, 2009
GMFTools Part 1: UI Extensions
This is the first of a short series of posts on GMFTools.
The Graphical Modeling Framework is a powerful framework for the development of graphical editors for EMF-based models. It's based on EMF and GEF and uses a model-driven approach for designing the editors.
Building graphical editors is a complex task. While GMF tries to facilitate that procedure, its abstractions are sometimes still a little hard to grasp, and the generated results often need manual fine-tunig to meet end-user expectations. I am a user, not a developer of GMF. Mymain concern is getting things done in the projects I am working on. That's why I sometimes bend GMF to do what I want it do, rather than use it the way it is meant to be used. That fact makes it somehow hard to contribute back to the GMF project. Still, me and my colleagues take a lot of benefit from using GMF.
GMFTools
As a long term user of GMF, I started to collect code, tools, samples and several tipps and tricks in the GMFTools project about a year ago. In the meantime, the project has attracted additional committers and it has become quite a useful collection of real-world solutions around GMF.
GMFTools roughly consists of three components
The first thing that may catch your attention after having installed GMFTools is a new GMF button in your button bar. It is meant to make GMF development easier and performs a bunch of actions on your GMF projects, including running the GMF code generator. To see what kind of actions, open the preference page for GMFTools. Each action can be enabled and disabled separately.
Most of the actions are self-explanatory. You may wonder why I want to delete the gmfgen model and the diagram code before re-generating. The reason is that by deleting the generated artifacts before re-generation, I circumvent all reconciliation steps (including JMerge). I have very bad experiences with reconcilers in general and so I prefer not to mix manually written and generated code. Some people have called me a "purist" for this attitude, but from my experience a clean separation will pay in the long run of a model-driven project.
As a consequence gmfgen model becomes a temporary artifact in the whole code generation procedure. To be able to modify the gmfgen model nevertheless, I have introduced a model-to-model transformation that is performed before generating the actual diagram code from the gmfgen model. This transformation is performed using an Xtend file (both oAW and M2T work) which is persisted next to your GMF design models.
The fix of the type registration will be covered in a post on shared editing domains.
In the middle of the preferences, you can manipulate your current set of GMF models (might not be the best name), i.e. the combinations of ecore, genmodel, gmfgraph, gmftool and gmfmap models you need to generate a GMF editor, as well as the Xtend transformation. These sets can also be provided by means of *.def files that can be stored in your workspace next to the design models.
By a single click on the GMF button, all enabled actions are executed on the currently / last selected models. In its drop-down menu you can access all your editor model individually. That really speeds up GMF development significantly, as you no longer have to find your way through the popup menus of different files. Nevertheless, individual actions can still be executed from the popup menus of the respective files.
That's all for today. Stay tuned for more.
The Graphical Modeling Framework is a powerful framework for the development of graphical editors for EMF-based models. It's based on EMF and GEF and uses a model-driven approach for designing the editors.
Building graphical editors is a complex task. While GMF tries to facilitate that procedure, its abstractions are sometimes still a little hard to grasp, and the generated results often need manual fine-tunig to meet end-user expectations. I am a user, not a developer of GMF. Mymain concern is getting things done in the projects I am working on. That's why I sometimes bend GMF to do what I want it do, rather than use it the way it is meant to be used. That fact makes it somehow hard to contribute back to the GMF project. Still, me and my colleagues take a lot of benefit from using GMF.
GMFTools
As a long term user of GMF, I started to collect code, tools, samples and several tipps and tricks in the GMFTools project about a year ago. In the meantime, the project has attracted additional committers and it has become quite a useful collection of real-world solutions around GMF.
GMFTools roughly consists of three components
- UI-Extensions making GMF easier to use.
- Runtime extensions that add new functionality by means of additional classes and generator template changes.
- Examples demonstrating the use of the runtime extensions.
The first thing that may catch your attention after having installed GMFTools is a new GMF button in your button bar. It is meant to make GMF development easier and performs a bunch of actions on your GMF projects, including running the GMF code generator. To see what kind of actions, open the preference page for GMFTools. Each action can be enabled and disabled separately.
Most of the actions are self-explanatory. You may wonder why I want to delete the gmfgen model and the diagram code before re-generating. The reason is that by deleting the generated artifacts before re-generation, I circumvent all reconciliation steps (including JMerge). I have very bad experiences with reconcilers in general and so I prefer not to mix manually written and generated code. Some people have called me a "purist" for this attitude, but from my experience a clean separation will pay in the long run of a model-driven project.
As a consequence gmfgen model becomes a temporary artifact in the whole code generation procedure. To be able to modify the gmfgen model nevertheless, I have introduced a model-to-model transformation that is performed before generating the actual diagram code from the gmfgen model. This transformation is performed using an Xtend file (both oAW and M2T work) which is persisted next to your GMF design models.
The fix of the type registration will be covered in a post on shared editing domains.
In the middle of the preferences, you can manipulate your current set of GMF models (might not be the best name), i.e. the combinations of ecore, genmodel, gmfgraph, gmftool and gmfmap models you need to generate a GMF editor, as well as the Xtend transformation. These sets can also be provided by means of *.def files that can be stored in your workspace next to the design models.
By a single click on the GMF button, all enabled actions are executed on the currently / last selected models. In its drop-down menu you can access all your editor model individually. That really speeds up GMF development significantly, as you no longer have to find your way through the popup menus of different files. Nevertheless, individual actions can still be executed from the popup menus of the respective files.
That's all for today. Stay tuned for more.
Thursday, October 8, 2009
Eclipse Summit Europe 2009
I am looking forward to Eclipse Summit Europe 2009 in Ludwigsburg, Germany.
My colleagues from itemis and me, we're once again going to have our share:
Sebastian Zarnekow, Karsten Thoms, Markus Voelter and me are going to give a tutorial on Domain-specific Languages with Eclipse Modeling, in which we show how to set up your own easy-to-use MDSD toolchain.
In the short talk Combining Graphics and Text in Modeling Tools, Jos Warmer and me will be elaborating on mixing concrete syntaxes for the same model using state-of-the-art modeling tool frameworks such as Xtext and GMF.
In the talk Xtext - From Galileo to Helios, Sven Efftinge and Sebastian Zarnekow are presenting the future plans for Xtext.
Finally, Andreas Graf and Markus Voelter are going to talk on Leighweight Model-Driven Development for Embedded Systems.
So, maybe there's something in for you, too?
Monday, October 5, 2009
MacOSX window trouble
Clever people know that cleaning your keyboard while your computer is switched on might be a bad idea. I did anyway, and as a result my Eclipse window looked like this:
For the non MacOSX experts: You won't be able to click on the right restore button, and there is no such menu entry anywhere. Luckily, Eclipse can be restored using Window->New Window (thanks for the hint, Sebastian). Restarting the application or the computer would not work.
But how's that supposed to work in MacOSX anyway? I found a couple of Applescript solutions, but nothing really user-friendly in the internet. I couldn't even figure out how I got into this situation. Any ideas?
For the non MacOSX experts: You won't be able to click on the right restore button, and there is no such menu entry anywhere. Luckily, Eclipse can be restored using Window->New Window (thanks for the hint, Sebastian). Restarting the application or the computer would not work.
But how's that supposed to work in MacOSX anyway? I found a couple of Applescript solutions, but nothing really user-friendly in the internet. I couldn't even figure out how I got into this situation. Any ideas?
Friday, September 18, 2009
EMF Index
Work on the Eclipse project EMF Index has started. As the project lead, I am proud to present our new website http://eclipse.org/emfindex.
It's a bit plain - because I made it myself and I am not much of a designer - but still looks quite slick, as it is based on the Nova CSS. Heiko's webpages on Xtext have been a useful template.
Dennis and Sven have worked hard to finally get the automatic build running. You can download the latest snapshots
It's a bit plain - because I made it myself and I am not much of a designer - but still looks quite slick, as it is based on the Nova CSS. Heiko's webpages on Xtext have been a useful template.
Dennis and Sven have worked hard to finally get the automatic build running. You can download the latest snapshots
- the interim build update site: http://download.eclipse.org/modeling/emft/emfindex/updates/interim/
- the nightly build update site: http://download.eclipse.org/modeling/emft/emfindex/updates/nightly/
Monday, August 24, 2009
Xtext in Essen aftermath
Thursday was the hottest day this summer in Germany. But despite 30° C and thunderstorms a bunch of Java enthusiasts made it to the meeting of the ruhrjug, the Java user group in Essen (Germany).
Having a talk on Domain-specific Languages with Xtext was once again a refreshing experience, as the audience appeared very interested and posed a lot of intriguing questions. The whole thing has been recorded on video (sorry, it's in German), so you'll be able to see me sweating as soon as I have the link.
Thanks to Heiko Sippel and Peter Rossbach who organized the meeting and Prof. Dr. Michael Goedicke our host from the University of Essen/Duisburg at that night.
By the way, if you're hilarious about Xtext, don't forget to join our Model Prize Laureate competition and win a Google Phone, a ticket to the Eclipse Summit Europe or other fancy and geeky prizes!
PS: The video is now online. Watch me sweating at http://www.ruhrjug.de/videos/gse.lectures.app/Talk.html#Xtext.
Having a talk on Domain-specific Languages with Xtext was once again a refreshing experience, as the audience appeared very interested and posed a lot of intriguing questions. The whole thing has been recorded on video (sorry, it's in German), so you'll be able to see me sweating as soon as I have the link.
Thanks to Heiko Sippel and Peter Rossbach who organized the meeting and Prof. Dr. Michael Goedicke our host from the University of Essen/Duisburg at that night.
By the way, if you're hilarious about Xtext, don't forget to join our Model Prize Laureate competition and win a Google Phone, a ticket to the Eclipse Summit Europe or other fancy and geeky prizes!
PS: The video is now online. Watch me sweating at http://www.ruhrjug.de/videos/gse.lectures.app/Talk.html#Xtext.
Monday, August 17, 2009
Xtext in Essen
I'll be giving a talk on Domain-specific languages with Xtext to the Java User Group ruhrjug in Essen (Germany), Thursday the 20th of August, 18:30h.
So if you're based in the Ruhr area, bored by your summer holiday and keen to learn more about DSLs in practice, why not give it a try?
To avoid finding yourself in the wrong location, please note that this is the first ruhrjug event at the new location Glaspavillon Campus Essen.
So if you're based in the Ruhr area, bored by your summer holiday and keen to learn more about DSLs in practice, why not give it a try?
To avoid finding yourself in the wrong location, please note that this is the first ruhrjug event at the new location Glaspavillon Campus Essen.
Tuesday, July 28, 2009
Source code for the screencast of Xtext and GMF
Having received a lot of positive feedback for my last post, I finally found the time to make the source code available. You can find it in the SVN repository of the GMFTools project.
I have put the installation instructions here.
Note that this is proof-of-concept code rather than production quality. See my previous post for implementational details. Also note that two open bugs
currently limit the fun a little bit, but we're at least working on the Xtext part.
I have put the installation instructions here.
Note that this is proof-of-concept code rather than production quality. See my previous post for implementational details. Also note that two open bugs
currently limit the fun a little bit, but we're at least working on the Xtext part.
Sunday, June 21, 2009
Synchronized editors with TMF/Xtext and GMF
Well, here it is, the screencast showing a textual TMF/Xtext and a graphical GMF editor synchronized on the same model.
On the GMF side:
Additionally, I added a bit of glue code:
The editor are synchronizing on save, to avoid GMF's canonical edit policies pruning nodes/edges belonging to temporarily lost elements.
Xtext plays well with EMF. It registers
The example has been implemented with only a few changes to generated code: In Xtext, the following modifications were applied:
- A Formatter to define where to use what kind of whitespace, when the textual representation is derived from the semantic model.
- An IFragmentProvider that generates name-based fragments (IDs) for elements in an Xtext resource. That way, the correspondence of graphical nodes to semantic elements is preserved even if you delete a preceeding entity.
- An AbstractEntitiesJavaValidator has been implemented for Java based validation
On the GMF side:
- In the mapping model, I had to use feature initializers to make sure names are initialized properly on creation, to always have serializable models.
- In the generator model, I had to manually set the domain genmodel and the file extension.
- In the generator model, I enabled validation decorators and printing, and added the plug-in de.itemis.gmf.runtime.extensions from the GMFTools project containing a more sophisticated layout.
Additionally, I added a bit of glue code:
- An action to navigate from an EditPart to the textual representation, using Xtext's NodeAdapter.
- A listener that warns the user if (s)he's about to change a file that has already been changed in another dirty editor, and allows to abandon the changes.
The editor are synchronizing on save, to avoid GMF's canonical edit policies pruning nodes/edges belonging to temporarily lost elements.
Xtext plays well with EMF. It registers
- A resource factory for a specific XtextResource implementation that encapsulates the parser (text->model) as well as the serializer (model->text).
- An EValidator with a declarative Java implementation
Friday, June 19, 2009
Slides from Xtext Workshop at Code Generation 2009
Code Generation 2009 has been a lot of fun. Yesterday, Moritz, Sebastian and me gave a hands-on workshop on Xtext. Participants seemed to like it and we could even convince Steven Kelly from Metacase to give it a try. I've uploaded the slides to slideshare, so if you wish to learn something about Xtext, you can have a look at it here.
Back to Kiel, we are now sweating to give Xtext the last polish before it is released with Galileo.
Back to Kiel, we are now sweating to give Xtext the last polish before it is released with Galileo.
Tuesday, June 16, 2009
CodeGeneration 2009
I am back at Cambridge (UK) for this year's Code Generation conference.
The itemis-Kiel team already arrived yesterday, and after a nice walk through the town and some fish and chips, I finished a showcase with a GMF editor on an Xtext model. So be prepared for another converging editors screencast soon :-)
The conference started this morning. Up to now, I have heard two talks: First, Kathleen Dollard from AppVenture talked about Template Specialization. Kathleen referred to the .NET code generation languages and their specific problems, e.g. with respect to modularity and extensibility. To me it looked like we've got more comfortable solutions in the Eclipse/Java world. Then, Sven and Sebastian talked about Challenges in DSL Design. They elaborated that todays external DSLs usually stop at modeling behavior because of the lack of an embeddable expression language. Looks like that's going to be one of the goals in the next version of Xtext. Right now I am guarding the itemis booth for a while, just to join the case study by Karsten and Heiko on their MDSD projects at Deutsche Börse AG.
Despite all prejudice against British food, catering is excellent. Thanks to the perfect organisation by Mark Dalgarno and Andy Moorley, we're going on a traditional punting trip along the river Cam tonight. Should I have brought my wetsuit?
The itemis-Kiel team already arrived yesterday, and after a nice walk through the town and some fish and chips, I finished a showcase with a GMF editor on an Xtext model. So be prepared for another converging editors screencast soon :-)
The conference started this morning. Up to now, I have heard two talks: First, Kathleen Dollard from AppVenture talked about Template Specialization. Kathleen referred to the .NET code generation languages and their specific problems, e.g. with respect to modularity and extensibility. To me it looked like we've got more comfortable solutions in the Eclipse/Java world. Then, Sven and Sebastian talked about Challenges in DSL Design. They elaborated that todays external DSLs usually stop at modeling behavior because of the lack of an embeddable expression language. Looks like that's going to be one of the goals in the next version of Xtext. Right now I am guarding the itemis booth for a while, just to join the case study by Karsten and Heiko on their MDSD projects at Deutsche Börse AG.
Despite all prejudice against British food, catering is excellent. Thanks to the perfect organisation by Mark Dalgarno and Andy Moorley, we're going on a traditional punting trip along the river Cam tonight. Should I have brought my wetsuit?
Labels:
Cambridge,
CodeGeneration,
conference,
Eclipse,
GMF,
Xtext
Thursday, April 30, 2009
JAX is over, now head for Code Generation
The JAX 2009 conference in Mainz (Germany) was once again big fun: A good opportunity to meet lots of intriguing people and listen to entertaining and informative talks in a beautiful location at the river Rhine. I've just uploaded the slides of the talks I gave, so if you're interested, have a look at EMF - Beyond the Basic or Eclipse Modeling Overview.
If you're keen on modelling with double 'l' :-), I recommend to join the upcoming CodeGeneration 2009 in Cambridge (UK), 16th-18th June 2009. Next to a bunch of well known speakers from industry and research, my colleagues from itemis and me are also going to have our share on the programme, e.g. Challenges in DSL Design, Mastering differentiated MDSD requirements at Deutsche Boerse AG, MDD: The Good, The Bad and The Ugly, MDD: The Best, The Worst and The Ugliest, Language Definition, Extension and Composition with MPS and an Xtext Workshop.
Friday, April 17, 2009
Talks at JAX Conference in Germany
Sven and me, we're going to give some talks on Eclipse Modeling, DSLs and Xtext at the JAX conference in Mainz (Germany) next week:
Eclipse Modeling - Overview
Sven Efftinge, Jan Köhnlein
Tue 21/04/2009, 10:00-11:15h
Code generation in agile Projects
Sven Efftinge, Jan Köhnlein
Tue 21/04/2009, 16:45-17:45h
Xtext
Sven Efftinge
Wed 22/04/2009, 10:15-11:15h
EMF: Beyond the Basics
Jan Köhnlein
Wed 22/04/2009, 16:15-17:15h
Hope to see you there!
Tuesday, March 24, 2009
Xtext, Generic Editor and EMF Index at EclipseCon
Just finished our talks at EclipseCon.
First, Sven and me talked about the new TMF/Xtext. The room was so crowded that some listeners even had to sit on the floor. Presenting was really fun and given the feedback people are really excited for Xtext. So we are, even though Sven has a bad throat and almost lost his voice ;-)
Given the good resonance, we're trying to organize a BoF session on Xtext tomorrow. Stay tuned for exact time and location.
Sven had a 10 minutes talk on the Generic EMF Editor then, and showed the Editor, Xtend and Xpand. I think, it's a good idea to point people at the fancy features of the oAW languages, such as polymorphic dispatch and higher-order functions.
Finally, I gave a 10 minutes talk on EMF Index. I have the impression people were quite curious about that topic as we already mentioned that in our Xtext talk. I tried to prepare the slides in the presentation zen style, and I can just conclude that presenting is so much more fun than having a clutter of bullet pointed list. I hope, it's the same for the viewers. And I exactly hit the 10 mins :-)
EclipseCon is really great. You really meet lots of people in person you have only known from blogs or mailing lists. Having had my share, I can now relax and join the other talks on so many other interesting topics.
First, Sven and me talked about the new TMF/Xtext. The room was so crowded that some listeners even had to sit on the floor. Presenting was really fun and given the feedback people are really excited for Xtext. So we are, even though Sven has a bad throat and almost lost his voice ;-)
Given the good resonance, we're trying to organize a BoF session on Xtext tomorrow. Stay tuned for exact time and location.
Sven had a 10 minutes talk on the Generic EMF Editor then, and showed the Editor, Xtend and Xpand. I think, it's a good idea to point people at the fancy features of the oAW languages, such as polymorphic dispatch and higher-order functions.
Finally, I gave a 10 minutes talk on EMF Index. I have the impression people were quite curious about that topic as we already mentioned that in our Xtext talk. I tried to prepare the slides in the presentation zen style, and I can just conclude that presenting is so much more fun than having a clutter of bullet pointed list. I hope, it's the same for the viewers. And I exactly hit the 10 mins :-)
EclipseCon is really great. You really meet lots of people in person you have only known from blogs or mailing lists. Having had my share, I can now relax and join the other talks on so many other interesting topics.
Tuesday, March 10, 2009
EMF Index Creation Review
Tomorrow will be the creation review for the new EMFT subproject EMF Index. I am really looking forward to my first Eclipse project leadership and I hope everything will work out fine at the review.
EMF Index aims at indexing EMF models to allow scalable modeling tools with JDT-like comfort. So, if you have any objections against EMF Index, speak now (in the EMFT newsgroup) or remain silent forever ;-)
I am also glad to have the opportunity to present EMF Index at EclipseCon 2009 in Santa Clara. Looks like many of the interested parties will attend. I am going to give another talk together with Sven on Next generation textual DSLs with Xtext. It's also my first trip to the US, which makes me even more excited.
EMF Index aims at indexing EMF models to allow scalable modeling tools with JDT-like comfort. So, if you have any objections against EMF Index, speak now (in the EMFT newsgroup) or remain silent forever ;-)
I am also glad to have the opportunity to present EMF Index at EclipseCon 2009 in Santa Clara. Looks like many of the interested parties will attend. I am going to give another talk together with Sven on Next generation textual DSLs with Xtext. It's also my first trip to the US, which makes me even more excited.
Monday, February 2, 2009
Xtext Success Story
Just returned from a workshop in Switzerland. One of the guys there managed to
All of that within 5 days. What does that mean
It feels so good to have such a mighty toolstack at hand :-)
- Get acquainted with and install Eclipse.
- Install and learn oAW Xtext.
- Define a grammar and generate the code.
- Deploy the editor at the customer's side.
All of that within 5 days. What does that mean
- That guy is really a wizard.
- Eclipse is very easy to install and use.
- Xtext can really give you a head-start into modeling.
It feels so good to have such a mighty toolstack at hand :-)
Wednesday, January 28, 2009
OOP 2009
I am at the OOP 2009 conference in Munich. Lots of technical talks on software engineering, but soft skills are also a big topic. Even though our both is not really 80 square meters as promised, we are having lot of fun.
Yesterday, Sven and I had a talk on the introduction of three DSLs in a customer project: A textual DSL based on Xtext describing the domain model, a graphical DSL based on GMF for defining form layouts and an internal Java DSL for validation. I think we managed to entertaining the audience, as we made fancy slides in the "Presentation Zen" style. Measured by the amount of questions the talk was a success.
Yesterday, Sven and I had a talk on the introduction of three DSLs in a customer project: A textual DSL based on Xtext describing the domain model, a graphical DSL based on GMF for defining form layouts and an internal Java DSL for validation. I think we managed to entertaining the audience, as we made fancy slides in the "Presentation Zen" style. Measured by the amount of questions the talk was a success.
Tuesday, January 6, 2009
Proposal for new Eclipse Project: EMF Index
In the Modeling Symposium at Eclipse Summit Europe 2008 we discussed the necessity of an index for EMF models. Such an index would allow efficient queries for EMF model elements without actually loading the model resources, which is an enabling feature for powerful EMF modeling tools.
The proposal is now online. Please use the EMFT newsgroup for discussion. I am looking forward to your feedback.
The proposal is now online. Please use the EMFT newsgroup for discussion. I am looking forward to your feedback.
Subscribe to:
Posts (Atom)