This looks like a match made in heaven. Eclipse is a great IDE, but if one were just looking for an IDE, there are many alternatives. But I think I can safely say that the Eclipse ecosytem has no real competition. What makes Eclipse truly great is not the bundled Java development tools, but the powerful and highly adaptable platform design, and most importantly of all, the open, transparent, and quality-focussed community structure that the Eclipse Foundation has worked so hard to build. That allows anyone with a good idea -- and the resources to make it a reality -- to play in the same sandbox as everyone else. For me, there are two exemplars for the potential of the ecosystem to be much more than the sum of its parts.
- The Eclipse Modeling Tools, including EMF and related tools, are what brought me to Eclipse platform in the first place. If you want to do real-world Model Driven Software Development, it would be hard to make a case for anything else.
- Mylyn demonstrates the kind of practical invention that is possible when a platform is really open. It provides a unique task-focussed approach to development. Admission time: It takes a bit of up-front investment to really grok Mylyn, and I didn't take the time needed to really integrate it with my day-to-day development effort until I started working with Tasktop. Working on my own and setting my own tasks, I just never really thought I needed it. But now that I'm back working with a team of developers on a regular basis, with dozens of tasks to keep track of, I'd be seriously annoyed not to have it.
In many ways, the match was remarkably -- sometimes ridiculously -- easy. It is a really cool experience when you work with completely different technologies that have been designed for adaptation to arbitrary uses, and those designs actually work! In some cases, such as making the Ecore Tools project manager integration work with the modeling context bridge, the actual implementation (minus all of the project packaging, .xml bits, etc..) was only a few lines of code.
Still, the connection didn't seem quite so natural when the two got together for a first date. David Green had put together something similar a couple of years ago, so I knew it was possible. But would sparks fly? Text and tree editors are naturally places for approaches that constrain and contextualize data selections. Graph structures are even better. The problem is that most diagramming artifacts aren't really graph structures -- they're actually pretty (or let's be honest, usually not so pretty..) pictures of graph structures.
The typical approach to software model diagrams is to take a snapshot of entities and their relationships and stick them on the wall. And people get really attached to where different elements are on that wall. In fact, I think one of the greatest anti-patterns for graphical modeling tools is to treat the pictures as the most important artifact of all...but I'm getting off-topic. The important point is that for the common types of diagrams such as UML class diagrams and Ecore we can't really move things around. Or we can, but then they wouldn't be the same artifact anymore. Again, that's because with many diagram tools the layout and location of various entities have semantic meaning, or at least people treat them like they do. And in practice, GMF doesn't provide a facility for changing any aspect of the actual diagram without affecting the persisted model. That seems like a no-no for a tool like Mylyn which is intended to be assisting developers, not modifying artifacts.
Those who have worked with the GMF Runtime may not be surprised to hear me say that the mechanism for doing all of this didn't seem exactly straightforward. You know how some frameworks seem never to have met an abstraction that they didn't like? There are probably great reasons for every one of the levels of generalization provided by the decoration and related mechanisms, but taken together there were a lot of pieces to grok. Thankfully, the EMF Compare team had just done a similar integration so I was able to learn a lot from that. But with a few false starts and uncomfortable moments, I can happily report that the couple is doing quite well, and I'm happy to have played a small role in this little bit of bliss.
It's not quite "official" yet, but there should be a contribution to Eclipse quite soon. In the meantime, it's reasonably stable and works with Ecore Diagrams and Papyrus UML Class diagrams. Details are here and we'd appreciate your bug reports and especially ideas for improvements.
Oh, ok... while I was at it, I grabbed a video of the two in action. Was that wrong of me?