4 - Ed Merks of the EMF Project

[music]

Riyad Kalla: Welcome to episode 4 of 10 in the Eclipse on Callisto podcast Series, I'm your host Riyad Kalla. In this series we're interviewing key members from each of the Eclipse projects that will be included in The Eclipse-Callisto release. Today we will be interviewing Ed Merks who is part of the EMF Project, thank you for joining us today Ed. Why don't you start by giving us a description of what the EMF Project is all about, and what role it plays in Callisto.

Ed Merks: I'm somewhat tempted to start with jokes that it's both a floor wax and a dessert topping, there's definitely confusion about what EMF is, and it is many things at once.

Riyad Kalla: Right.

Ed Merks: Since it provides three fundamental building blocks, you can think of it as a model for describing other models or a metamodel, there's a runtime to emulate the behavior of your models, then there's a generator to generate a java implementation of your model, that you can specialize. So fundamentally you can think of EMF as a framework for converting various forms of models into a core model description. Into the Ecore model. So you could describe your model as annotated java, or as a schema, or as various flavors of UML.

Ed Merks: From that Ecore model, EMF is able to generate a complete java implementation of the model, for the full API of the model, is able to generate platform neutral editing support, that you can use in Eclipse for manipulating or viewing instances of the model. But other folks have used it with swing...or it could be used with nearly any graphical library. And finally, we can use it to generate an integrated Eclipse IDE or RCP editor for editing instances. And it's only that last piece, that's really tied hard to Eclipse...the code must have Eclipse to run. The model and the editing support can run without Eclipse.

Riyad Kalla: I see. Now how did the... for a lot of people, they hear the description of EMF, and they think... wow, metamodel of a model, it's pretty abstract. How did the EMF Project start and what was the motivation behind it? Was there a need that it was filling? How did you guys decide to start this project?

Ed Merks: Well EMF really started out as an implementation of OMG's metaobjects facility or "MOF". The primary motivation there was to drive data integration at IBM, you can imagine in a huge company like IBM, that there are just a huge set of models being developed, and if each of them were their own for the specialized flavor of how this should all work, they just wouldn't work very well together, so the idea really is to provide data integration, and for there to be some uniform way of accessing all the data so that all these models could refer to each other and interact properly. But, at that time, the MOF was addressing those needs, but MOF itself, the metamodel, was seen as overly complex. So there was a lot of things in it that people didn't use, and runtime performance was quite poor. And the generated code, looked like, generated code.

Ed Merks: It looked like something a machine would write, not a person. So the real motivation when I got involved, was to address all of those kinds of concerns, was to reduce the complexity of the metamodel, just reduce it to its basics, really focus on runtime performance, so that these things actually perform better, than what you would normally write by hand. And finally to focus on, making things template based, so that the code that you see, you can go and modify a template to change what kind of code comes out. So people can't really complain, I don't like how the code looks, because you can always play with that in the template, and get what you really want it to look like for free.

Riyad Kalla: Now you got involved in EMF after it became an Eclipse project or at IBM?

Ed Merks: At IBM, then it subsequently became an Eclipse project. I've always been fascinated by programming languages and language environments, even back to my University days in the eighties, my PhD Supervisor, Rob Cameron, worked on something called GRAMS, grammar based metaprogramming system. And in that you could essentially start with a specialized BNF grammar Backus-Naur form grammar to specify so that the grammar of a programming language, and then from that he would generate to the printers and parsers and all the API's. So in a sense EMF, the Ecore model is really just like a grammar and what we're doing, it's really similar to what he was doing back in the eighties.

Riyad Kalla: Wow! Now I've spoken to a few of my friends, who are Eclipse Developers, And they do plug-in developments, some GAF's some SWTJ Face Stuff, and none of them understood what EMF was, and so I've kind of seen this divide with the developers, on forums and things. The ones that tried EMF and get it, and then the ones that are just boggled by it, and don't even want to bother with it. Do you think there are questions or kind of signs that a developer could look for on their own projects to know if EMF is the type of thing that would help them out. Are there certain types of projects that lend themselves very well to EMF? Or are there...Give me an idea of what a developer...what are hints they could look for to say, hey ok maybe I'll go check out this EMF thing, this might help me.

Ed Merks: Yeah I guess in a sense, you can think almost anything can be modelled, right... so if you think of as you're defining your data structure, that's really where EMF can come into play, in the definition of the data structures itself, much less so in terms of behavior of your data, that's ultimately going to involve writing methods with statements in them that specify how things work. But in terms of declaring your data, you look at all the different forms of modelling, and it's all very similar, in a schema you define a complex type with a name, and it's got an element, you know elements to describe the data that's in that type. And Java, you define an interface with a name, and getters and setters, and in Ecore, you have e-classes with structural features, so really it comes down to the question. Is your code manipulating data that needs to be persisted and needs to interact with other data?

Ed Merks: If it does, then it probably makes sense to try to model those, and come up with a formal model for your data. And then that model will interact better with everyone else's models. But there is definitely places where it doesn't make a lot of sense to try to apply it. Like I wouldn't imagine trying to write for the SWT Library widgets using a model type of approach. But definitely in a lot of things like PDE there are a lot of models of the plugin XML, the manifest dot MS. All kind of things that logically you can think of as models where it definitely would be applicable.

Riyad Kalla: I see, now you mentioned before, that developers exporting their EMF models, and using like a SWING interface. How easy is it to pull EMF, or use EMF outside of an Eclipse runtime, if someone wanted to use it in an application, on the client side...server side, anything like that, is that a fairly easy thing to do?

Ed Merks: Yeah, the more we try to generate the JARS you end up generating, that's part of generating your project, they will run stand-alone. There is nothing you need to do to make them work stand-alone. So it's just a matter of putting them on the class path, and you are all set. We have been very careful in the architecture, to find where the boundary line is between things that work stand-alone, and things that require Eclipse to run, and definitely all of the model code, and the sort of item provider, the dot edit support as we call it, is all intended to work stand-alone, and be retargetable to any environment.

Riyad Kalla: All right Ed, so we were talking here for a second, and I pointed out that I'm not familiar with EMF at all. And I was trying to map the idea of EMF to something I am familiar with, and as a web developer, I've always seen EMF examples given for client side applications, you know.. modeling, profile information, or project structure, so on and so forth, so if, using something I'm familiar with, let's say in hibernate, I'm writing a web application, and it's a company that has employees, and these employees have contact information and addresses, so on and so forth. And that's a pretty textbook example of POJO relationships in kind of a textbook hibernate example. So, what I would do currently, is sit down and start writing these classes in Eclipse, just hand coding the whole thing. I'm wondering if this is the type of thing that, I could instead model using Ecore, and then have EMF generate the model for me.

Ed Merks: Yeah, most definitely you could use it to do something like that. You could imagine that you had a schema to describe the model, then you could just generate all this stuff from the schema, if you were really a Java programmer and didn't want to learn all the Ecore stuff, you could start by just writing the interfaces for these objects and marking them up with model annotation, and then EMF is able to read those annotations.

Ed Merks: Basically you could start with something that has a same Interface A, with a get X method that returns an N, then you just add models on both of those things, and EMF would be able to generate an Ecore model from that, and then when you generate, you build to generate the info for that, and a factory for creating instances, you'd right away have the serialization and deserialization support for it, with the new EMFT project, the Teneo project, being donated by Martin Taal, you would actually get the hibernate support for free as well because he is providing the hibernate integration. Certainly you could do all of this kind of stuff with EMF directly, and write very little of your code, most of it would just be generated for you.

Riyad Kalla: Now how does EMF, the generated code, how does it handle, or does it handle monitoring changes, you know setter changes, things like that, on my generated classes.

Ed Merks: There is a whole notification framework, so that all changes to your model are, well produced notifications, that have enough data in them so that you'll know exactly what's been changed. So obviously that's something you can use to keep a GUI up-to-date, with the state of the model. But it has more applications then that, for example, we use it in our change recorder, to record all of the changes that happen in the model. And that change recorder, when it is sort of computed, where all of the changes are, is able to encode those changes as what is called a change description. It is yet another model in EMF, and that changes description you can then use to apply to the model, to kind of undo them.

Ed Merks: So you could imagine in a dialog, letting a user make a bunch of changes, and when they are done, you could say cancel, and it would undo all of the changes. Or it can be used to support undoability in a command. Or even more interesting is, as your editing your model, you record all the changes, and you send back only the description of the changes, rather than sending back the changed model. And then the server side having to do a big dip, and see what changed, can literately can send a description of the changes. I might say this one objects name was changed, or this one object was added.

Riyad Kalla: So just the delta, the performance implications are huge obviously for big models.

Ed Merks: Yeah, exactly, instead of sending a thousand lists, with a thousand things with one thing added to it, you just send an instruction that this one thing was added.

Riyad Kalla: Now this...I'm sure a lot of people are starting to drool here, and get the idea. The idea that EMF, this metadata, models, and modeling of models is starting to... I'm starting to understand it a little better here. We talked about earlier, Ecore is the grammar, and you currently ship with a Java generator. Is there work, or ideas to put in place at some point, other generators for other languages?

Ed Merks: Not one that we would do so much, definitely other groups have done things like this. I know there was a group in Germany, that generated a C implementation of their model from the information in Ecore. And another group that I knew of generated a web application for manipulating instances of models from the Ecore descriptions. So, definitely in this release, we made a more extensible generator framework, that allows you to reuse the genmodels as we call it, that's used to generate the Java code. You can reuse that and apply it to different templates, to generate all kinds of other artifacts. That's really the thing you kind of see. The GMF Project was doing something for the graphical editor.

Riyad Kalla: Right.

Ed Merks: It's really a matter of creative ideas, and making them real.

Riyad Kalla: Now getting started, lets say I'm a developer, and now all of a sudden after listening to this podcast, I decide I got to get me some EMF. You mentioned before, starting with schemas, maybe that's something that people are more familiar with. Having a schema and running it through EMF plugin and having it generate a grammar. Are schemas...and then you also mentioned...before I continue, starting with interfaces...going the reverse direction...from code to Ecore... What do you think the best way for someone to start is? And what do you think as they become more advanced and more familiar with EMF, you think they should just code directly to the Ecore grammar, or do you think they should keep going with something easier?

Ed Merks: It really depends on the style or preference people want to work in...what we're trying to do is support many different styles rather than argue not one is best. So if you have a schema, if you have a well defined serialization format, than starting with the schema, certainly a very simple and easy approach to follow, and then we've got the tutorial and cheat sheets that show you all the steps you need to take to end up with an editor, that will edit valid instances of the schema, it's great if you have one of those, but if you don't know schema at all, that's probably a really poor place to start.

Ed Merks: If you're really just sort of a Java programmer, and you don't know a lot of UML, and you don't want to learn about schemas. Just starting with your Java interfaces, and using the @model annotations, is probably the preferred approach. Certainly the one that I see from the green newbies, that haven't bought into all this modeling stuff. It's often the approach they like best, because all they need to do is learn some of the @model syntax and everything else is their familiar Java environment.

Ed Merks: It's good to think of the Ecore model as sort of a hub, that other forms of models descriptions can be converted to Ecore. So you can take a schema, convert it to Ecore...you can take UML..convert it...annotated Java..and then once you have Ecore you can actually generate any of the other forms as well. So if you do have an Ecore model, you can export it as a Schema...and that will describe the XML serialization of your instances. So it's a pretty powerful thing, having a hub, it's a little like the way the airport systems work...a hub is just very good, because it's easy to connect lots of different things, without having a gazillion different cross routes in between them all.

Riyad Kalla: Right....right now are there...I think you mentioned earlier, there's some issues with using the schema, that are a little more generic than some of the specifications...are there performance implications? From generating your Ecore from a schema, or using interfaces?

Ed Merks: No not really...you ultimately end up with the same model...but when it comes to the serialization of the model...if you did start with a schema, then you want your serialization to exactly respect that schema. So the annotations that get generated on your Ecore model, will drive that serialization process. I do imagine that might be a little slower to exactly emulate a particular schema how it wants serialization to work...as supposed to sort of an XMI style serialization...

Riyad Kalla: Now I've seen EMF, as a lot of people know, some of the more obscure uses have caught me off guard...I believe this is correct...but I heard that WTP uses EMF to model their projects...and TPTP uses EMF for the profiling data...is that correct?

Ed Merks: Yeah definitely...

Riyad Kalla: ok so that's pretty interesting...it sounds...at least what I've seen.. is that EMF is used in quite a few of the projects under the Eclipse umbrella...and also quite a few projects that went into the Callisto release. Was there a lot of collaboration with the EMF team and other teams to get ready for Callisto? Or was everything they needed there...and you guys were just on autopilot?

Ed Merks: There was certainly some collaboration. We pay a lot of attention to what we hear from the community to help guide us, and we like to do the work that will benefit the most people the most. When we look at other teams using EMF we realise they also have a community and by helping them we help their community, which is just kind of a multiplier effect. I wouldn't say we collaborate particularly closely with all the other projects. Most of the time we view all of our clients on a bit of an equal footing and take everybody's issue at face value and give some credibility. But we do think about how do you help the most people the most because we are a very small team and we really need to focus on where we can contribute a lot and not on 'nice to haves' that are not essential.

Riyad Kalla: How big is the team right now?

Ed Merks: Elena Litani is on maternity leave. So normally with her as a part of the team we would have three full time developers and then myself as well. So there's Dave Steinberg, Marcelo Paternostro and Elena Litani are the primary developers. I'm also a developer. Nick Boldt does all the web build infrastructure and things like that. We're lucky enough to have two co-op students right now but that's very short term.

Riyad Kalla: I see. Now is there a project in particular either under the eclipse umbrella commercial or otherwise that is a primary consumer of EMF that you've gotten the most feedback from or you worked the closest with?

Ed Merks: No, we really get feedback from the diverse community itself. So I wouldn't single anyone out as providing the most feedback. I suppose in some ways we work the most closely with the UML2 project because it's also very much modeling related. But no particular team stands out as sort of we work with them the most closely and paid the most attention to them, we tried to spread ourselves perhaps a little too thin on occasion.

Riyad Kalla: Now from the first release of EMF up until recently what project or team has provided the most surprising feedback on EMF, usage feedback, saying hey guys we need to be able to do this and this and really caught you off guard as far as, oh well, that's not something we ever thought about.

Ed Merks: Not so much. EMF was in use within IBM for a long time. Well, not for a long time but the precursors to EMF were many years before we started on it. So by the time it did become an open source project the majority of difficult requirements had already been serviced at that point.

Riyad Kalla: I see.

Ed Merks: Things have been generally smooth. EMF was fairly matured going back to 2002 so it's fairly mature. We've seen more a growing list of really nice to have as opposed to the show stopping we can't do it unless we have this type of thing.

Riyad Kalla: I see. Right. Now one of the biggest strengths you touched on earlier in EMF is the ability to combine hand written code with the generated code. That's certainly not an easy thing to do. What've been the biggest hurdles implementing that functionality and not just generating everything in machine code.

Ed Merks: Yeah, it's kind of funny because that's certainly one of the most important things about the code generator is that you can do the merging but think about how much work went into defining that. We're really talking about maybe two weeks of coding work that makes something like that work. So it was quite a simple idea and actually turned out to be quite simple to implement as well so it really didn't turn out to be a big challenge given that the JDTs got this very nice JDOM API that we use for analyzing the Java code and could use some nice regular expressions in Java to do pattern matching. Between those two things it was shockingly simple to implement something so powerful.

Riyad Kalla: Good to hear. EMF, you mentioned, one of the original implementations back in IBM, the generated code was just very machine like and horrible to use. So it seems to me and people have noticed this with EMF is that the generated code now is very human readable, very friendly. Is that something that's been a huge focus so every time a change or an addition is made you really evaluate, okay, we need to generate good code here or was that just something that came in passing?

Ed Merks: It was certainly one of the key driving points to produce code that people wouldn't say this is just garbage to look at. If you look at a lot of the machine generated code you'll see things like all class names are fully qualified. Cause that makes it easier to generate code that's not going to have name conflicts but no human being would ever write code like that. Code like that is quite unreadable. So definitely the focus was make this code readable. But if you think about it often the best code is the code that's written in the most terse manner. Efficiency comes from not doing redundant things so producing code that's terse, that only does the basic necessary things, really tends to also produce the most efficient code.

Riyad Kalla: Right.

Ed Merks: There's not a huge conflict there. If you look at the generated codes you'll see the getters return a variable that's exactly what you would expect and no more. If you look at some of the generated setters for single valued properties you'll see some notification code and some other more complex things. But that's the extent of the complexity. If you look at it closely it's all pretty straight forward in what it's doing. Typically I don't see a big conflict between what's good code to generate, what will perform well versus looks, human readable, will be nice to read. Usually they line up nicely.

Riyad Kalla: I see. We had an interview with the GMF team earlier this week. They had a lot of references to the UML2 project and seems pretty tight nit. I know when GEF came out for a long time as well as UML2 project a lot of people were saying why isn't there a GEF designer for UML2. The GMF project touched on how that's something they're working on. It seems like all these modeling projects are really tightly nit together. You had mentioned some collaboration with the UML2 project because it's also a modeling project. Has EMF played a big role in the development of the UML2 project or vice versa? Are these projects all...

Ed Merks: Definitely we had a big influence on the UML2 project. It started after EMF was already available and people could really see that EMF was generating models with good runtime performance and could basically scale even to huge models like UML2. So definitely that collaboration was very close, mostly in the one direction. We helped sort of influence the UML work. There's some discussion about EMF being small end modeling where UML is big end modeling. The distinction is EMF is focused on fine grained data integration, making this stuff all pragmatic and useful, right at the grassroots.

Ed Merks: Well... UML is much more a grand unified modeling vision, the big picture that OMG is trying to sell people on. Sometimes it's hard to convince people of this big unified vision where as something like EMF that appeals a bit to laziness, right? You have a schema, you hit a button, you have an editor that's working like that. You don't need to be convinced that modeling is the greatest thing in the world. You saved yourself several weeks of work.

Riyad Kalla: Right. Exactly. Now EMF has the ability to realize improvements not only in obviously the code itself but also the code it generates. Now with the release of EMF in Callisto what are some of the improvements you're most excited about that you would like other people to know of?

Ed Merks: Well, definitely EMF has been all very incremental so a lot of small changes that we make, people might not even notice or be aware of, in fact. In the previous release we added a capability where we're basically noticing that if you have a boolean variable, that variable takes up four bytes, and really to represent a boolean you only need one bit.

Ed Merks: We also add things like unsettable features where we needed a separate four byte boolean to indicated the unset state. Somebody noticed at one point, look you have this eflags variable that's got 30 bits in it that aren't being used. Why don't you represent these things as bits? So basically we added an option to say, generate your booleans and unsettable features using bit flags. So there are people's models where they applied this new pattern and were able to reduce an instance object size from 230 bytes down to 100 bytes.

Riyad Kalla: Oh wow.

Ed Merks: Generating... So that's one of the powers behind this whole pattern based generator approach. All you need is one person with a creative idea and suddenly everyone with a push of a button can exploit the value of that idea. One that's current to the 2.2 release is we changed all the patterns for the generated eGets and eSets. They would be based on feature IDs instead of on the feature object so that when people call that message directly that's performance optimization. It also enabled us to build to call super without having to recalculate the feature ID on every call to super. That's probably the most significant pattern change for this release. It may be something people don't notice at all.

Riyad Kalla: Now are you guys getting a lot of these optimizations suggested from the community and other projects, or is it mostly internally the team says, 'oh hey, this is interesting', and they notice this and that?

Ed Merks: A lot of times people will complain about some particular type of performance issue and then we scratch our heads and try to come up with something that will either give them additional flexibility. During the previous release we were very much focused on performance of SDO, but the SDO effort has really moved to Apache now. It's still based on EMF 2.2 but moved to Apache so this latest release we were a little more focused on footprint type of issues, trying to reduce instance size. Definitely we always want to keep feeding people those incremental improvements. The fact that people don't necessarily notice they're coming is sort of a good thing. You don't want to create a burden for people every single release. You'd rather that they take advantage if they can or ignore it if they don't care.

Riyad Kalla: That actually leads into my next question. As you guys are making these changes, so far the ones you mentioned sound like someone can just hit a button and regenerate their model, now all of a sudden they have these performance benefits. Are there concerns with API breakages where, say, a project is getting ready to make a new release and they regenerate their model and there's possibly a change in the new version of EMF that now all of a sudden may cause a break in their code, is that a big concern for the team?

Ed Merks: It's definitely a concern but one that we try to keep internally so that no one else ever has this concern. I believe it's still the case if you have a model that was generated by EMF 1.0.0 that you can recompile that against the latest runtime without regenerating your code.

Riyad Kalla: Oh wow.

Ed Merks: Regenerating the code in general should not introduce any problems if you got the proper markup, the new things will get merged properly and then the things you don't want touched will remain untouched. As far as I know, no one's complained about 'I regenerate my code and now it's broken'. That's really not been an issue. There is one minor issue in the current release that if somebody wants to regenerate a derived model but the base model's not been regenerated then this new reflective egap pattern will get them into trouble. So we did encourage everyone to regenerate their model but I'm not sure everyone has.

Riyad Kalla: Where there any compromises in 2.2 that needed to be made or features put on the back burner to maintain compatibility?

Ed Merks: No, not really. I guess we would've liked to have started the Java 5.0 work sooner. That's kind of a contentious thing. But, no, we don't feel like we've had to make a lot of compromises or been restricted in the types of changes that we'd like to make because of the generator patterns issue. If anything, the biggest restrictions we find are sort of caused by ourselves in that we tend to be very open with our APIs that we allow people to... we have a lot of protected things. So people can derive and then go crazy in their derive class to access things. So if anything, that's kind of our biggest stumbling block with respect to maintaining forward momentum without breaking people.

Riyad Kalla: You indicated Java five support. I'm assuming you mean Java five in the generated code?

Ed Merks: Yeah, exactly. Once we have our runtime we need to provide it in both places. We have, like... our elist interface is something that we really need to templatize and then the user would expect to see a method like get content that returns an elist of whatever types of things are in the list. So it's a combination of templatizing our core runtime or generifying it, whatever the term is, and then also changing the generator to produce code that exploits that.

Riyad Kalla: Is this because of user demand or did you guys just see the writing on the wall that this is work that just needs to get done at some point?

Ed Merks: There's a little bit of user demand but we take both user demands with a grain of salt because there's an endless list of things that people would love to have. The writing's on the wall as well. Java is at the 1.6 or 6.0 stage so by the time we GA next year, Java will be a 6.0 level and if we don't yet exploit or take advantage of our allowed users to do that for 5.0 we're really leaving people high and dry.

Riyad Kalla: I see.

Ed Merks: Definitely one contentious issue, this came up a lot at the Eclipse architecture council meeting last week, a little bit of the 'nobody wants to be the first one to cause Eclipse to have to move'. Soon as someone makes that decision then everybody's effected by it and EMF, definitely being at the bottom of the food chain, will impact most other clients. But people were pretty comfortable with us paving the way and gaining the experience and then we'll be able to give other people advice and help with moving their APIs forward. In theory we should be able to do it in a binary compatible way. That's certainly possible in the JDK itself. That will be our goal to do this in a non-disruptive manner, hopefully, preserving binary compatibility.

Riyad Kalla: Now, moving forward, looking towards, I believe, it's the Europa release next year of Eclipse, what features does the EMF team or what things are the EMF team working on that you're looking forward to most having besides the Java five support we mentioned?

Ed Merks: Gosh, that's almost the primary one. I've been putting together a plan and a schedule for what work items we can contain but this Java five item is just so encompassing and sweeping it's hard to imagine much other significant work being done in addition to that.

Riyad Kalla: Do you foresee it taking up a majority, almost exclusively, of the time until the Europa drop starts showing up?

Ed Merks: Yeah, I believe so. Unless we can start getting more community involvement and collaboration then we're really going to be burning the midnight oil on the Java 5.0 stuff. It may turn out to be a pleasant surprise and not nearly as difficult as I expected but our preliminary work indicates that it's pretty complex stuff to understand.

Riyad Kalla: Now, given the complexity of generating code and the changes you're talking about, are you seeing a lot of community support. EMF isn't the type of thing you pick up an afternoon and start coding for. It's pretty heavy work, right?

Ed Merks: Yeah, I suppose. But the tutorials are pretty trivial so if you have a model, that's one of the easiest avenues for people to play with is if you have a schema then really you don't need to know much. You can follow the tutorial steps. In 2.2 now we have very nice cheat sheets that one of our co-op students worked on. So following one of these cheat sheets with your own schema library certainly gives you a working result without you having to know Java or much else about Eclipse.

Riyad Kalla: For folks wanting to get started with EMF would you say that the EMF and the tutorials is the best resource?

Ed Merks: Yeah, definitely.

Riyad Kalla: Well, Ed, we're getting towards the end of this podcast. Is there anything you wanted to add before we wrap up?

Ed Merks: I guess the comment I was making earlier about people getting involved. We're a tiny team. We've got many, many good ideas. The community has many good ideas. We definitely would like to see more people involved as committers or contributors in the project. So people want to get involved and do more than just exploit EMF but help contribute to it, we'd be sure happy to hear from them.

Riyad Kalla: Great. We want to thank our guest Ed Merks from the EMF project for taking the time to sit down and talk with us about the role his project will play in the Eclipse Callisto release. We appreciate everyone tuning in and hope you enjoyed yourselves. This concludes episode four of 10 in the Eclipse on Callisto podcast series.


[music]

Transcription by CastingWords