1 - Richard Gronback of the GMF Project

[start music]

Riyad Kalla: All right, welcome to episode one of ten in Eclipse Zone Callisto podcast series. I'm your host Riyad Kalla. In this series we are interviewing key members from each of the eclipse projects that will be included in the Eclipse Callisto release. Today we will be interviewing Richard Gronback who is part of the GMF project. Thanks for joining us today Richard. Why don't we start with you giving us a description of what the GMF project is all about, and what role it plays in the Callisto release?

Richard Gronback: Okay, sure, and thanks for having me.

Riyad Kalla: Sure.

Richard Gronback: So, GMF is really about making it simpler to create graphical editing type applications within Eclipse. That was really the driving force behind it. Within Callisto it really just complements I guess EMF and GEF as other Callisto components in bringing more of a visual and graphical modelling aspect to development within Eclipse.

Riyad Kalla: And then, how did the GMF project come about? Were you guys solving a problem that everyone was complaining about, or did you just think "Hey, this would be neat if we shorten the ramp-up time for modelling in Eclipse?"

Richard Gronback: Well really both. There had been a lot of attempts made at combining the aspects of GEF, the Graphical Editing Framework, and EMF, the Eclipse Modelling Framework in the production of a graphical editor within Eclipse. And there has been an IBM Redbook written on the subject. Many, many people had done very similar things internally, and so it was thought by many that it would be great for there to be something that was able to bind these two other projects, and make it much simpler for people to create these graphical editors. So, that was the real thing that got us started. Just in general to reduce the complexity of developing graphical applications with EMF and GEF.

Riyad Kalla: I see. So, as people are working on these graphical editors using EMF and GEF they are resolving the same problems over and over again and that's where GMF comes in?

Richard Gronback: Yea, primarily the problem was that both EMF and GEF, and even the platform had their own command infrastructures, so you would have to do a lot of wiring together of that. Different approaches were taken. It was thought that if there was one solid approach that was generalized then that would be very helpful.

Riyad Kalla: I see. And then how did you get involved in the project?

Richard Gronback: I guess a year and a half ago Borland became a strategic developer member of Eclipse, and with that comes the requirement that you lead a project. So, I was asked to, I guess, invent a project, and so I sat down and wrote up a proposal for GMF, which combined the elements I just talked about with a model-driven approach so that you really develop these graphical editors using a series of models. A model for the graphical part, a model for the domain, obviously from EMF, and then another model that describes your tooling, and then another model that maps them all together. It's really a very model-driven approach to generating graphical editors.

Riyad Kalla: Has this been a pretty smooth project to work on? It seems to me that GMF came out, and then fairly quickly you were able to create some pretty usable things with it right off the bat. It didn't seem like it was in incubation for two years or anything like that.

Richard Gronback: Technically, we are still in incubation, until next week, I guess.

Riyad Kalla: Okay.

Richard Gronback: When we finally release the 1.0, but we've had our release reviews so we're set to exit incubation as soon as Callisto ships. It was a fairly smooth process. Since so many people had done something very similar, there were a number of contribution reviews that we did initially when we formed the project. A number of organizations presented what they had done. Many had done things very similarly. IBM had a large contribution that added a lot of these capabilities in a run-time, which was ultimately selected to be one of the contributions to start the project, and then the Borland team was focused on the generative side the model driven side of it, where we target that contributed run-time.

Riyad Kalla: I see. I was just going to ask is there, you kind of hinted at this, is there a lot of collaboration between your team and specific other teams.

Richard Gronback: Yeah. Within GMF there are two main components; the run-time and the tooling. And they are pretty much divided along the Borland and IBM lines. Although, we would like to improve that, and have a little more cross team work and collaboration going on. But then obviously we have collaboration with EMF and GEF, although not to as great of an extent as you might think. GEF primarily has been provided for by that run-time. They built on top of GEF in the run-time. And so we target that run-time. That team initially, I'm sure, had a lot of interaction with GEF, but really EMF I guess, is the primary thing we've been working with.

Riyad Kalla: Okay, I see. As you guys have been developing GMF, what have been the biggest hurdles that you've had to overcome to create this framework, and allow it to be as smooth as you need it to be?

Richard Gronback: There's been a number of things along the way that have changed. One being that when the initial contribution came in, it had a lot of components that were more related to EMF, and then as I mentioned there are some that are related to GEF. And so we had a split of what is now the EMF technology project. OCL and validation and transaction, and query elements that were initially in GMF were split off into another project. There was just a bit of coordination that had to take place for the transition of that codebase, and then obviously some contributors went with it, away from GMF to the EMF-T project. And then that presented another dependency for our builds, so that we had several elements from another project again to consider as far as how to build our GMF. That's pretty much the biggest, but actually it went very smoothly.

Riyad Kalla: What has the schedule been like for the Callisto release? Is the new technology team, and then GEF and EMF all synchronizing with the GMF? Or, is everyone kind of working on their own and things are falling into place as they need to for Callisto?

Richard Gronback: For Callisto we stagger it according to the layer of dependencies, with platform being at zero, I guess. And then EMF and GEF really don't have any other dependencies other than platform. They were required through the phases of Callisto to be released within a week after the platform for each milestone. And then since we are dependant upon both EMF and GEF that put us at what's called the +2 level. So, we had another week on top of EMF and GEF to build ours. The only real complication was EMF-T piece I mentioned because technically, they built on EMF. That would have introduced another one week since we depended on it. Technically, we were a +3, but the teams worked really well to make sure that that didn't present a problem. We were actually able to always be on time at the +2 level even though we had that extra set of EMF-T dependency builds in the middle.

Riyad Kalla: I see, and then how does the GMT project fit in to all of this?

Richard Gronback: Well it doesn't, really.

Riyad Kalla: Oh, Okay.

Richard Gronback: So GMT is classified as a research project, really. It's a place where new emerging technologies in the generative modelling tool space are worked on, and hope to emerge into other projects, perhaps within Eclipse. Within the new modelling project that was formed a top level project, it will remain this incubator and research project. Really it's a quite involved project. It has so many little elements within it that I think there aren't too many people who understand what's within GMT very well. Including members of the new modelling EMC. So what we've asked John Visavine[sp] to do is to give us a closer look into GMT and to find what's really there, because it's pretty big.

Riyad Kalla: Ok. We saw on the website, and then other people if they go to the website they notice there's a lot of good tutorials, a lot of good information, and a lot of examples including UML tools, UML tool modelling and mind-maps. Is the idea that someone can pick up GMF and create a designer for languages like that just out the gate and get a functional tool going in a week or two?

Richard Gronback: Well, yea, actually. That is the goal. I don't know about the week or two part, but certainly. As another example, that I've started working on for a tutorial for a conference coming up I took the BPMN, or Business Process Modelling Notation spec and I started from scratch with the spec and created a domain model with an EMF. And then I created the associated models within GMF to generate a rather decently featured BPMN modelling tool. That took about a half a day. There's quite a bit of advantages to using GMF, obviously the time effort that it takes. But the idea is that you should take any domain model, really, and create a graphical editor for it in a very short amount of time, and Mind-map is just one that I thought would be interesting to do myself. So I added that. That's actually the tutorial for GMF is a Mind-map application. It's a very simple domain model, but it's very illustrative of how to get started with GMF. UML2 is another domain model that exists already within Eclipse. So, it's already there for us, all we will need to do is create the graphical definitions and tooling, and mapping models. And that's already been started, actually. One of our team members has already started the class and state diagram definitions. I would expect after GMF one is released, we'll be much more active in producing those UML definitions.

Riyad Kalla: Oh, I see. That's just where I was leading to. So, there is an effort for other projects under Eclipse to start consuming GMF like the UML2 project. I think a lot of people have seen sitting there for a while and it's just extremely robust. It just doesn't have the graphical front end to, say, download and start modelling your software with. Is that an official project that GMF and UML2 projects are going to collaborate on? The design?

Richard Gronback: We've had some communication already with Kenn Hussey, who's the project lead of UML2 project. So the intention is for us to contribute these diagrams to that project and then have it finally available to people who want to model UML2 with a diagramming aspect.

Riyad Kalla: And then what other projects are consuming GMF, because it seems that there's other designers in there. I know WTP is a pretty broad scoped project. But it seems some of the JSF tooling, or things like that? Are they going to start consuming GMF and using it for their diagram editors, things along those lines?

Richard Gronback: Well, that's the hope. The hope is that anybody that has a need for a graphical editor will use GMF. Unfortunately, a lot of these graphical services that already exist in Eclipse were already done before GMF. So, they're done either just with GEF or even sometimes just with SWT, even. But I think the data tools project is one that I spoke with back at EclipseCon, and they mentioned they would like to use GMF for some data modelling. That's a very appropriate application of it. It depends, really, on the type of editing you have in mind. But it really is the goal for everyone to leverage it.

Riyad Kalla: How realistic is it to take an existing GEF editor, and convert it to GMF? Or is it a total re-write, and it's going to be a lot of work for most people?

Richard Gronback: Well, you can take your existing figures that you've coded in Java and you can use those in GMF. We allow you to just point it, basically, at a figure class that you've written already and then bring that into the graphic editor that is generated. There's a bit of reuse available.

Riyad Kalla: And then, it seems to me like you guys have really gone out of your way to create a very transparent set of guidelines, and tutorials, and information on the GMF site so any contributors or any other projects that want to utilize GMF, or even external contributors that want to work with the GMF project can kick back contributions. Has a lot of GMF's development been collaboration with other teams, or other teams sending back requirements to your contributions, or even individuals saying "Hey, it would really be great if it did this, and this, and this, and here's a patch".

Richard Gronback: I'd say that those documents that you mentioned as far as development guidelines and how to get started and set up your environment, and everything, those have been leveraged I think, I'm hoping, to a great extent by our current list of contributors. And they generally fall on the teams from IBM and Borland, unfortunately. I think it's problematic for people to arrive at GMF - at least in the 1.0 days because it was developing so quickly, at least on the tooling side was changing all the time. It might have been a little daunting for people to come in, and try to contribute to it, because everything changed so quickly. But hopefully after 1.0 is released, and there are some nice little isolated features that folks can work on, that those documents will be used by a broader community of contributors that will submit those as patches through Bugzilla. I'm hoping that they get more use in the future, but right now they've been pretty much used by the existing teams, although we have had some contributions through patches. We've had really a lot of good community feedback and support of the tool but not as many patches I guess, as we would like to see.

Riyad Kalla: Now, given your initial vision of GMF, what you wanted to do, and let's say the initial team's vision, and what they wanted to do. How close is the 1.0 release? Is there still ways to go, or did you nail what you mostly wanted to nail in the 1.0 release?

Richard Gronback: I would have liked to see a little more. From my initial idea of what 1.0 would be, I expected a little more, I guess. But the reality of bootstrapping our own editors proved that really there is a lot of work to be done in order to have usable bootstrapped set of editors for the different models we use. So, the idea we had was that our graphical definition model, our optical definition model, and our mapping model would all have definitions for them, and that we would bootstrap those graphical editors for our own models with GMF. This has worked fairly well, it's just that they're not as clean-cut, I guess, or as useable as we would like. So, for not we are sticking mostly to generated EMF editors for models, and that we have in the experimental SDK download a WYSIWYG type editor for the graphical definitions so you are able to see the figures that you are designing, and you are able to link those to the nodes that will be represented on the diagram. It will just take a little longer, that's all.

Riyad Kalla: We notice that already on the wiki, the Eclipse wiki you guys have the GMF 2.0 project plan, and you have some things targeted for that release. What are the big items that are going to be in GMF2 that you want to address?

Richard Gronback: Well, that WYSIWYG editor really is one of the things that will be most useful because designing a figure in the provided EMF editor is a little painful. So, to have it be WYSIWYG would be a very helpful thing for people getting started with GMF. The other thing would be, the thing I would like to see is the RCP application generation features, so that we're able to completely generate an RCP based application with a graphical editor. EMF already has an option for it, RCP based. We really just want to extend that so that you will be able to generate a really lightweight diagramming surface for a RCP application. So, that's another one of the big wish list items.

Riyad Kalla: Ok, no major API breakage, or anything like that?


Richard; Well, the tooling models, being very new in the 1.0 we do anticipate that those models, once they get used by a broader community and get beat up, they probably will have some significant changes. We anticipate a 2.0 release for the next release rather than a 1.1 perhaps because API breakage that we expect.

Riyad Kalla: I see, Ok. And then, let's zoom out of a second, and let's say we had users that are saying "Hey, I want to get busy with Eclipse. I want to start creating some modelling tools. I'm at work; we've got this custom language. I want to model processes" or something like that. And they wanted to get started with a designer. What would you suggest how they would attack that? Just go to the GMF site and start reading tutorials? Do you have other tips for them?

Richard Gronback: I think the tutorial would be the best first step, if they are looking to use the generative aspects. They can always use the runtime by itself. The runtime was designed to be manually extended as well so that you can just use a runtime component and code and craft your own graphical editors with GMF. And then that API we expect to be very stable. It's more the tooling side API we expect to have some flux in the next release. If they get started with the tutorial they will get a really good idea of how to get started. And again, I guess the domain model itself is always very important to get right. Without a good domain model, it's going to be more difficult to create a good graphical editor.

Riyad Kalla: We are getting close to the end of this podcast. Is there anything else you wanted to add before we sign out?

Richard Gronback: Well, I guess maybe just a couple of things. One would just be a plug for the new top-level modelling project, which will, I guess, will help people navigate the modelling projects that are available in Eclipse. And, as we mentioned with the UML2 graphical aspect that we plan to add, the thinking is now that that will end up within something model development tools project, which will be a project within the top-level project. That's where folks would come, the end-user type community would come, to find modelling tools. There's a diagram, I model on it. Rather than a "This is a framework for generating this. This is a framework for generating that".

Riyad Kalla: What kind of timeframe are you guys looking at for having that out if people are really interested in what you are talking about?

Richard Gronback: The PMC has really been preoccupied with Callisto, so I expect after next week, we'll all have a lot of time, or we'll have more time to sit down and take a close look at how to organize the project. The contributions for those, for the UML2 stuff I would expect to come right after the Callisto release. It shouldn't take too long. We are hoping that with the Europa release, which is the next version of Callisto, next year, that the modeling project will have a much more understandable scope and charter, that the community will see rather than what it is today, which is a little confusing.

Riyad Kalla: Well, we wanted to thank our guest Richard Gronback from the GMF project for taking the time to sit down and talk to us about his role in the GMF project, as well as the GMF project's role in the Eclipse Callisto release. We appreciate everyone tuning in and hope they enjoyed themselves, and this concludes episode one of ten in the Eclipse Zone Callisto podcast series. Thanks Richard.

Richard Gronback: Thank you.


[end music]

Transcription by CastingWords