Eclipse Amalgam: ‘The Helios Release is a Fresh Start for this Project.’
With the Eclipse Helios release train out of the door, JAXenter speaks with about Eclipse Modeling committer Cédric Brun about the Amalgam project.
Cédric leads the EMF Compare component, is a commiter on several Eclipse Modeling projects (Acceleo, Amalgamation), and is a member of both the Eclipse Architecture and Planning Councils. As a product architect at Obeo, he is the technical lead of Obeo Designer and works on software evolution, re-engineering and cartography of legacy systems; all through model driven processes. He has graduated from the Polytech engineering school, has a research Master at the University of Nantes, and has specialised in software engineering and model driven engineering. Prior to his current employment, he has been an active contributor to open source and worked in Guangzhou on a global video conference solution for the Chinese Education and Research Network (CERNET).
On June 23rd, 2010, the Amalgam project was released as part of the annual Eclipse Simultanous Release Train. Below, JAXenter speaks with Amalgam committer Cédric Brun, about the changes afoot at Amalgam since Obeo took over as project lead, and the project’s plans for an Eclipse Indigo release……
JAXenter: Can you describe the Amalgam project in a few words?
Cédric Brun: The amalgam project is part of the Eclipse Modeling project, its goal is to provide a consistent modeling environment while integrating the numerous Eclipse Modeling subprojects. Our work is focused on providing a convenient Eclipse Modeling package, simplifying the discovery of the diverse community we have in modeling and demonstrating through examples how one can combine those technologies.
JAXenter: Who is behind the project, and where did the original idea come from?
Cédric Brun: The project has been created by Richard Gronback, it was originally created because of the following users and adopters’ feedback: “the modeling technologies are too complex, not integrated enough and lacking documentation.” In answer to those complaints Richard started to work on the ‘Eclipse Modeling as a DSL Toolkit’ book and created the Amalgam project: a support for this book. It took two years to complete the book and to provide the first usable Eclipse distributions for the Eclipse Modeling project. At that time there were three distributions: one hosted in the Eclipse Packaging Project included each and every Eclipse Modeling Component, a ‘Toolsmith’ focused one was dedicated to the definition of domain specific tooling and a ‘Modeler’ one was dedicated to analysts and developers.
Splitting the packages using roles looked like a good idea, but it was implying too much. The burden of testing and maintaining those packages was too high for a single man project and it was assuming the adopter was able to choose between those three distributions, which turned out to be quite complicated.
At some point, Borland, Richard’s employer, decided to stop being involved in Eclipse and the project stalled for a few months until we (Obeo) decided to take over the project lead and carry on maintaining it.
JAXenter: How advanced is the development of Amalgam, in the Helios Release?
Cédric Brun: The Helios release is a fresh start for this project, a new team of commiters from several companies gathered in order to make the Eclipse Modeling Package a showcase for the Modeling Project. We started by changing the massive, all-in-one distribution into a smaller, progressive one including core components and we worked on integrating a discovery mechanism so that the adopters can easily browse and install complementary projects from Eclipse Modeling. That’s a huge gain for the user as the package has been slimmed down from a whopping 500Mb to less than 250Mb. Testing and making sure the core package has a consistent user interface has been made possible thanks to those changes.
The package includes all you need to start working with EMF: the core framework and the CDO model repository, and the ability to semantically compare and merge any models stored on CVS, SVN or even GIT.
You also have specific integration for Java code generated by EMF allowing you to filter generated code from your workspace or easily spot user-customized code. And, last but not least, the package provides you with a graphical modeler for Ecore, which is a ‘class diagram like’ formalism. This is provided out of the box, but you can easily extend your environment with some projects through the specific discovery UI we provided and install, for instance, Acceleo to design your own code generators in a few clicks.
JAXenter: What do you perceive to be the main benefits of model driven software development? And, how do you answer those alleging that MDSD has failed, due to the substantial effort needed to maintain the generated code?
Cédric Brun: I’m applying MDSD and the benefits I see everyday are: adapting to changes more easily, pushing consistency in the code base and easing integration of new developers in the team as best practices are captured in the generation templates. Measuring productivity gains is nonsense if you only measure those during the development phases, the gains you get from MDSD, you get during the software maintenance phase way after the first release.
That said, many tried to apply MDSD with black-boxed tools, complex external modelers designed by third parties and a constrained top to bottom development process. This fails for obvious reasons, the development team is not adopting the tool because it’s getting in the way, any change you need to make in the generated code will have to go through a “bug/patch/release/deploy” cycle in the code generator. I’m not even describing the scenario with multiple people trying to collaboratively work on a proprietary model. People tend to think that’s mandatory for model based developments but it is plain wrong, you can leverage MDSD in an agile way.
A development tool should not get in the way of the developer allowing him to have control over the code generation, it should have the lowest possible barriers for using it and it should be perfectly integrated with the IDE. That is exactly what Acceleo is providing for code generation: providing you more control and the lowest possible cost to start using it.
You can leverage MDSD without having a heavy and hierarchical process, even just for a single project, you might have a big boost of productivity, quality and consistency with the code by just defining a small set of generator templates perfectly tailored to what you want. Most modeling projects are falling in the category of very pragmatic tools you can leverage in many contexts, but this is something we still need to evangelize.
JAXenter: What are the next steps for Amalgam?
Cédric Brun: We are trying to go further in providing a consistent and powerful platform while avoiding what made the project fail at first. One of the lessons learned i : we should involve all the other projects toward this goal, and that means, once again, giving them more control.
For the Helios release, this involvement took place through the discovery user interface, the project had to provide summary, logos and descriptions to be visible; we’d like to go one step further for Eclipse Indigo and, maybe, try and tackle the examples and documentation needs with the other Modeling projects.
On the other side, we’ll work on streamlining the package with the following goal : providing a high quality product for modeling technologies. As it is the first release since the team rebirth, we’ll be very mindful of the users feedback.
JAXenter: If you had to pick which football team most closely resembles Amalgam, which football team would it be?
Cédric Brun: I would pick Argentina, a team aggregating individuals, great by themselves, but taking it to a whole new level by making them play together.