tag:blogger.com,1999:blog-36585020961857881772024-03-19T00:42:59.765-07:00Eclipse mdeLaurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.comBlogger32125tag:blogger.com,1999:blog-3658502096185788177.post-84334666874086826402013-06-03T01:28:00.001-07:002013-06-03T02:30:30.108-07:00EMF Compare - GMF strikes backHere we are, <a href="http://wiki.eclipse.org/EMF_Compare">EMF Compare</a> 2.1.0 is just around the corner. This was a very exciting, yet very busy year. EMF Compare 2.0 was released last summer, laying out the foundations for all of the cool stuff we wanted to (but could not) include. Now, 2.1.0 comes to fill the gap between the 1.* and 2.* streams, most notably through the re-introduction of support for graphical comparisons.<br />
<br />
So what can you really expect from Compare 2.1? Let's skip the project life and focus on the cool features that can now be used.<br />
<br />
<b>Graphical Comparison</b><br />
<br />
We introduced a "preview" support of the graphical display of differences into the project in its fifth milestone (M5) <a href="http://eclipsemde.blogspot.fr/2013/02/emf-and-graphical-comparison-whats-in.html">back in february</a>. This was one of the biggest features we wanted to polish for the release, and polished it has been :).<br />
<br />
This support is quite generic, and it should be able to handle most GMF-based modelers without too much work from their side (a few extensions are needed to tell EMF Compare how to open their diagrams). For now, our primary target was <a href="http://www.eclipse.org/papyrus/">Papyrus</a>.<br />
<br />
Though the differences themselves were all pretty well detected, we were not happy with how they were displayed in this first draft. The decorators we use to tell the users "what changed in there?" were thus our primary focus. Here are a few examples of the differences that can be detected in Papyrus UML diagrams... and how we display them in said diagrams.<br />
<ul>
<li><i>Adding a Class</i><br />
Both "new" and "old" models are displayed, on the left and right sides respectively. The Class "A" has been added : it is highlighted in the left (new) diagram, and a transparent placeholder for its shape is shown over the right (old) diagram.<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5NfXgTXqh707XIP0RMf5X8WeCw-owpZJu1GPlR5ZQqktRH9U8NoXcCLOy7gTTtM5OCP9tW8VfrJk0Wdsvo5cQTj3y19txwa_1NI-qN5ganQYLABwYCJkYHh4G8K-vNN2VsWxUBZVzWd0b/s1600/AddClassA.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5NfXgTXqh707XIP0RMf5X8WeCw-owpZJu1GPlR5ZQqktRH9U8NoXcCLOy7gTTtM5OCP9tW8VfrJk0Wdsvo5cQTj3y19txwa_1NI-qN5ganQYLABwYCJkYHh4G8K-vNN2VsWxUBZVzWd0b/s400/AddClassA.PNG" width="400" /></a></div>
</li>
<li><i>Removing a feature</i><br />
Within lists, the placeholder is shown as a single line:<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsnE6w5C1dN1urimh0dKhXPcfVr5b7CZSgsA7oAp88-FzLP1AlFIpIqDcMlyYPbovFX67yYLy6jX2Wh2MlaJ1ZJWxP0hzY_YYt9__5wRTYCDxv1BtsncmUtBUswxK-JJczhM0fYLQMHDWG/s1600/DeleteFeature2.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsnE6w5C1dN1urimh0dKhXPcfVr5b7CZSgsA7oAp88-FzLP1AlFIpIqDcMlyYPbovFX67yYLy6jX2Wh2MlaJ1ZJWxP0hzY_YYt9__5wRTYCDxv1BtsncmUtBUswxK-JJczhM0fYLQMHDWG/s400/DeleteFeature2.PNG" width="400" /></a></div>
</li>
<li><i>And if we need some context to understand the change?</i><br />
Some changes cannot be understood if shown alone. For example, cascading differences (delete a package and all of its content) need some context to understand the differences related to said "content". Likewise, if we delete both sides of an association along with the association itself, we'll need contextual information to understand the association difference. This is handled through lighter-colored placeholders.<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqGtwFNDs_7nCSyl65SyxF8EXEN5GSRISeJLBKr2kjoyCHwIc3J493Fy6L3ONKIQvQOAjPc0K66TscnErH59PDHgz434tjxn_bgF6wjqhTlVQ76pyTmrYjiQqpcS0X87vErV2VjV3vDOMu/s1600/ContextNodes.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqGtwFNDs_7nCSyl65SyxF8EXEN5GSRISeJLBKr2kjoyCHwIc3J493Fy6L3ONKIQvQOAjPc0K66TscnErH59PDHgz434tjxn_bgF6wjqhTlVQ76pyTmrYjiQqpcS0X87vErV2VjV3vDOMu/s400/ContextNodes.PNG" width="400" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8YW_doZnMnv1blos54LxBm-MDEyQuXZniXC78C674QVYj66sMNEyxn3GKIhr3PHiAhV0H8btkekgOA-M_T_LtP6AjjKVNbX2HXL0cx6Qo_m6PnOFIhzkH8nWkFjYeZe3SoMLs7uMJyBdE/s1600/ContextEdges.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8YW_doZnMnv1blos54LxBm-MDEyQuXZniXC78C674QVYj66sMNEyxn3GKIhr3PHiAhV0H8btkekgOA-M_T_LtP6AjjKVNbX2HXL0cx6Qo_m6PnOFIhzkH8nWkFjYeZe3SoMLs7uMJyBdE/s400/ContextEdges.PNG" width="400" /></a></div>
</li>
<li><i>What about conflicts?</i><br />
In case of conflicts, we try and highlight all related information on all three sides of the comparison:<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2lrct-Ze4DzY8JvIVxnf5RS1LqNNe_SySplHvywCI9OB0ca0DJy5gXFqsRs5kBo0LoUVnkCr9y3yOEeprvpK-EqR4aTWBnC3_cIGUulwySPHG8u1-37I5C1OY-Sx8GxFGIuJMCmMXXowS/s1600/Conflict.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2lrct-Ze4DzY8JvIVxnf5RS1LqNNe_SySplHvywCI9OB0ca0DJy5gXFqsRs5kBo0LoUVnkCr9y3yOEeprvpK-EqR4aTWBnC3_cIGUulwySPHG8u1-37I5C1OY-Sx8GxFGIuJMCmMXXowS/s400/Conflict.PNG" width="400" /></a></div>
</li>
</ul>
<b>Comparing models without identifiers</b><br />
<br />
One of the hardest part of comparing EMF models is that we need to "match" the elements contained by these models together. When we are given two instances of a given model in two different versions, we need a way to tell that some package "library" in the first version is the same element as the package "library" in the second version. Likewise, we need to be able to tell that the attribute "pages" of a class "Book" in the first is the same as the attribute "length" of the class "Book" in the second version before we can even tell that there is a difference on that attribute (it has been renamed).<br />
<br />
When we have identifiers in our model, this is an easy matter. We assume that the identifier of one given object has not changed between the two versions. However, this is not always (rarely, in fact) the case. EMF Compare 2.1.0 re-introduces support for such models, computing and matching objects through their similarity. For example, here is the result of comparing two ecore files together:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiEgjaFngkMe0Sh-8YgSkG_SczM90eSgkOX8Ei14NjAldoE8cFHK-lle_SQLNVCQ9LOpKp5Pd1s_n4fkAXRpYdBIeNhDBGeJc-8UVjjDHRBC92P5s5h1PW-ylrR5dft8Z8nsvVG-DDR1id/s1600/ecore_tree_compare.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="288" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiEgjaFngkMe0Sh-8YgSkG_SczM90eSgkOX8Ei14NjAldoE8cFHK-lle_SQLNVCQ9LOpKp5Pd1s_n4fkAXRpYdBIeNhDBGeJc-8UVjjDHRBC92P5s5h1PW-ylrR5dft8Z8nsvVG-DDR1id/s400/ecore_tree_compare.png" width="400" /></a></div>
<b>Enhanced user experience</b><br />
<br />
The amout of data we compute is quite large, reflecting the accuracy we desire for the comparison; and the number of differences between two versions of the same model can be daunting. We strived to improve the comparison UI in order to provide a much more precise and intelligible information. We've used two means to that end, both of which can be extended by clients of the API.<br />
<ul>
<li><i>Grouping differences together</i><br />
By default, EMF Compare does not group differences, and simply displays them as they've been detected:
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS9p0h_Xd6qCWsVLB3lXLgOJaaBymGHE0rBUsm784y_BqV9F_Am4eIbGcvY6oItSUNjdUmAdQ1ob68cuhLkyS7cqfTpUeOsBv47_5q76AStZ0AwL1IkKF1_lnA6c3MadpyTLKTkZJx0JQR/s1600/EMF_Compare_Groups_Default.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS9p0h_Xd6qCWsVLB3lXLgOJaaBymGHE0rBUsm784y_BqV9F_Am4eIbGcvY6oItSUNjdUmAdQ1ob68cuhLkyS7cqfTpUeOsBv47_5q76AStZ0AwL1IkKF1_lnA6c3MadpyTLKTkZJx0JQR/s1600/EMF_Compare_Groups_Default.png" /></a></div>
One of the options we provide by default lets you group these differences according to their originating side (in the case of three-way comparisons, comparing with a remotely controlled version for example), along with a special group for the conflicts (if any):<br /><div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi13YTaDVCwjgg1m8t-imUiGVSJJmwGlrkiUD4-L23PcOcTFwZycN7mBMSOqJ8MXbgyP20tL6EMsgK3r5JGVqcVpB4Pg4LiiLfugxwdOpdi-e3kxae6jWSFPMrHNtvD0-QATn8fa9DLbGua/s1600/EMF_Compare_Groups_Side.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi13YTaDVCwjgg1m8t-imUiGVSJJmwGlrkiUD4-L23PcOcTFwZycN7mBMSOqJ8MXbgyP20tL6EMsgK3r5JGVqcVpB4Pg4LiiLfugxwdOpdi-e3kxae6jWSFPMrHNtvD0-QATn8fa9DLbGua/s1600/EMF_Compare_Groups_Side.png" /></a></div>
</li>
<li><i>Filtering differences out of the view</i><br />
A second option (of course, both can be combined) to limit the number of visible information is to filter out differences that could be considered somewhat as "noise". For example, EMF Compare detects all differences within the containment tree: if the Class "Book" has been removed, then of course its attribute "pages" has been removed. And in turn, the "type" of this attribute has been unset. Those are three differences resulting from a single one. By default, EMF Compare will not display the "resulting" differences, focusing on the "root" only:
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEif4LKKHDUW0syBmklR3JaeP6Cj2-HB-r17Glu_r-Anzq4dOXENaj4ChfWpes-528VrKpvyTaJnH6Y4cTEjYsZYTr3TJpzkChKSCIUMu01qvajhEighxJixTwBL9KXlsW70EqnYuEke-Hdb/s1600/EMFC_Filtered.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEif4LKKHDUW0syBmklR3JaeP6Cj2-HB-r17Glu_r-Anzq4dOXENaj4ChfWpes-528VrKpvyTaJnH6Y4cTEjYsZYTr3TJpzkChKSCIUMu01qvajhEighxJixTwBL9KXlsW70EqnYuEke-Hdb/s1600/EMFC_Filtered.png" /></a></div>
However, they are still computed, and they are still there in the comparison. We called these "cascading" differences, and users can choose to have them displayed instead by unticking the associated filter:
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZEJvN83V1dERES6tlG6QrjAXzhBzcLSpOsCACJplT7WAcHxvFp8nUsvttwtk4yqIqxMNS8DuwnS7P37iAlTns2Kfxr0zBdyUYMzr6cWcH5IWle9E8UTllCAsWGKHvGJ4v4_jmznzgiYqe/s1600/EMFC_Unfiltered.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZEJvN83V1dERES6tlG6QrjAXzhBzcLSpOsCACJplT7WAcHxvFp8nUsvttwtk4yqIqxMNS8DuwnS7P37iAlTns2Kfxr0zBdyUYMzr6cWcH5IWle9E8UTllCAsWGKHvGJ4v4_jmznzgiYqe/s1600/EMFC_Unfiltered.png" /></a></div>
</li>
</ul>
<br />
This has already become too long of a post (kudos if you read all the way till here ;)). Anyone interested in the full list of enhancements and highlights of this release can find it <a href="http://wiki.eclipse.org/EMF_Compare/ReleaseReview/Kepler#Release_Highlights">here on the project's wiki</a>, with a little more details.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com3tag:blogger.com,1999:blog-3658502096185788177.post-12273569640096053742013-02-14T02:36:00.000-08:002013-02-14T02:42:39.699-08:00EMF and Graphical comparison - what's in the pipeline?A lot of things are being worked on for EMF Compare, and while we're polishing the core and refining the user-interface, a few new features have been included in the latest milestones. The biggest focus is on the graphical (GMF) comparison and displaying of differences:<br />
<br />
<b>Graphical Comparison</b><br />
<br />
It's been a while since I mentionned that <a href="http://wiki.eclipse.org/EMF_Compare/Specifications/GraphicalComparison">graphical comparison</a> with EMF Compare 2 <a href="http://eclipsemde.blogspot.fr/2012/11/diagram-comparison-with-emf-compare-2.html">was coming</a>. Well, the feature has been included as a preview in the M5 milestone of EMF Compare (which can be installed from <a href="http://download.eclipse.org/modeling/emf/compare/updates/milestones/2.1/S201302050831">this update site</a>). We can now properly detect and merge graphical differences in GMF models.<br />
<br />
However, we have now initiated a more thorough reflection on how to <i>display</i> these graphical differences. Our preliminary implementation is not satisfactory:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0yoHf9kCYQqy4r_PVM44oB6Jzs_9mFgHB3F8MH7IdWNh3Y5Jn0a0V_eHa4ml0wq4pc908hFikv-fNvHykhxN-CvPuxJhU-lD1kFRq3wChF3YUnZBfoPPFznf2ufRDxps5I89_pgNQipMK/s1600/EMFC_Diagram_Compare.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="189" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0yoHf9kCYQqy4r_PVM44oB6Jzs_9mFgHB3F8MH7IdWNh3Y5Jn0a0V_eHa4ml0wq4pc908hFikv-fNvHykhxN-CvPuxJhU-lD1kFRq3wChF3YUnZBfoPPFznf2ufRDxps5I89_pgNQipMK/s320/EMFC_Diagram_Compare.png" width="320" /></a></div>
Should we use a custom color code or reuse the "team" colors (those that show on the icon's overlays), should be draw a rectangle "around" the differences or decorate the existing figure's borders, how can we best show that an element has been deleted?<br />
<br />
We are trying to determine how these differences would be best displayed... and your opinion matters :). If you think you can help on this reflection, or wish to share any thought on this point, the specification of what we expect the graphical display to look like can be found on <a href="http://wiki.eclipse.org/EMF_Compare/Specifications/GraphicalComparison">the wiki</a>. We've initiated <a href="http://www.eclipse.org/forums/index.php/t/453251/">a thread on the compare forum</a> for the discussion to take place for anyone interested.<br />
<br />
Two special integration features for Papyrus and Ecoretools are also
contributed, though these only include means to detect "label"
differences and may be temporary: labels are computed when displayed,
potentially from many distinct other features... thus detecting and
merging them is very costly. For the technical, we have to create
off-screen editparts and compare the labels textually. Merging
requires calls to the direct edit tool when there is one. These
integration features may not be kept in the final release. <br />
<br />
<b>User Interface</b><br />
<br />
The second most visible change that's coming with this M5 milestone of EMF Compare is a deep modification of how differences are displayed in the structural view. In short, we previously had a very long sentence that tried to describe the changes in details:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgwn-AJ9l2d7z17s-jW6t73B-fKJ-QKa_v0ofhdDOjI1K3DZJxbxpnCxzzwq2ZGaFZrz90xMU_9KG-mC4zBvulprm0mUY_UZSxz87ltvItdUf1o80ajasg3_cQ78qS4xh1Ra8lelZAOqlY/s1600/EMFCompare2-Labels.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="258" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgwn-AJ9l2d7z17s-jW6t73B-fKJ-QKa_v0ofhdDOjI1K3DZJxbxpnCxzzwq2ZGaFZrz90xMU_9KG-mC4zBvulprm0mUY_UZSxz87ltvItdUf1o80ajasg3_cQ78qS4xh1Ra8lelZAOqlY/s320/EMFCompare2-Labels.png" width="320" /></a></div>
While we have reduced this to the bare minimum <i>useful</i> information with this new version:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://wiki.eclipse.org/images/4/4c/EMFCompare2-StyledLabels_v3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="270" src="http://wiki.eclipse.org/images/4/4c/EMFCompare2-StyledLabels_v3.png" width="320" /></a></div>
We expect that the simple label, along with the change icon (remote, local, conflict...), will be enough to understand what happened in the model. We add the name of the feature that actually changed along with the type of difference we detected as additional information.<br />
<br />
The content viewers (the two/three panes displayed as the bottom half of the comparison editor) are also expected to change before Kepler is live. Namely, we are currently changing the way we show the differences in their context. Currently, the only context we offer is the list of siblings of the changed element:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaY-9G5zhZtMvni6zusrY3UjSd6OEzgy2kLcNX2A6jncGiT-h_t2U_Dc3QI8EnUVyHUgMhIlYozUzn_7FlkUctZDem-YpdIo8ybMUOCYjmGf4mM8FM2r-CHttkMdr4YR1Ij7dEqlBDRGxL/s1600/emfcompare2.1_list.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="222" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaY-9G5zhZtMvni6zusrY3UjSd6OEzgy2kLcNX2A6jncGiT-h_t2U_Dc3QI8EnUVyHUgMhIlYozUzn_7FlkUctZDem-YpdIo8ybMUOCYjmGf4mM8FM2r-CHttkMdr4YR1Ij7dEqlBDRGxL/s320/emfcompare2.1_list.png" width="320" /></a></div>
For containment changes, this is quite disturbing, and we are changing that to display the whole tree instead (along with the other containment changes detected during this comparison:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj98cRXzkziK3Eiz6mvfaF8uUPRjcSzVPwQA_Q62ktDkMWIO9BXcbPG_weBB408LCtk7L8LSrpnMZns-mjfSGT0fS55Lu417MbSRzekI-R6VEQwyjWwERl5djartMeKFp-TEKYc2RieKYm2/s1600/emfcompare2.1_containmentRefTree.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="207" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj98cRXzkziK3Eiz6mvfaF8uUPRjcSzVPwQA_Q62ktDkMWIO9BXcbPG_weBB408LCtk7L8LSrpnMZns-mjfSGT0fS55Lu417MbSRzekI-R6VEQwyjWwERl5djartMeKFp-TEKYc2RieKYm2/s320/emfcompare2.1_containmentRefTree.png" width="320" /></a></div>
<br />
<br />
<b>Extensibility</b><br />
<br />
EMF Compare is thought and implemented as a framework, and we are striving to provide all extensibility means that could be necessary to tweak, customize or replace the comparison and merging processes. I won't go in much detail here, more information on each possibility will be added to <a href="http://wiki.eclipse.org/EMF_Compare/Developer_Guide#Default_behavior_and_extensibility">the wiki</a>, or questions can be asked on <a href="http://www.eclipse.org/forums/index.php/f/164/">the forum</a>.<br />
<ul>
<li><a href="http://wiki.eclipse.org/EMF_Compare/Developer_Guide#Default_behavior_and_extensibility">Customize the comparison process</a>: Most steps of the comparison process can be modified, be it the matching, differencing, detection of equivalences, detection of conflicts, resolution of the logical model...</li>
<li><a href="http://wiki.eclipse.org/EMF_Compare/Specifications/MergeExtension">Custom mergers</a>: We now provide an extensible merging framework so that extenders (or users) can alter the default behavior or contribute their own merging policy for either default or custom differences.</li>
<li><a href="http://wiki.eclipse.org/EMF_Compare/Specifications/ExtensionPointForFiltersAndGroups">Filtering or grouping differences</a>: Differences displayed in the structural view can be filtered and/or grouped together. A number of default options are provided, but new ones can be added seamlessly through extension points.</li>
<li>Customized user interface: There are a number of entry points to customize the user interface of EMF Compare. For example, the graphical comparison we were discussing above is entirely contributed to the EMF Compare UI as an extension. Clients can also tweak the labels and icons of the differences, contribute new toolbar actions, ... This is a part that still lacks good documentation, feel free to get in touch through the <a href="http://www.eclipse.org/forums/index.php/f/164/">forum</a> if you need more details on this. </li>
</ul>
Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-24953415214294483812012-11-30T08:07:00.000-08:002012-11-30T08:07:43.856-08:00Diagram Comparison with EMF Compare 2We have had a number of questions regarding the diagram comparison support in EMF Compare 2. This is something that was (somewhat) provided with EMF Compare 1.3, but that we have yet to port to the new version of the APIs.<br />
<br />
Well, the work is ongoing and preliminary support for diagram comparison is available in the current integration builds. The port was done in the context of the <a href="http://wiki.eclipse.org/ModelingPlatform">modeling platform working group</a> and is mainly targetting Papyrus, though ecoretools diagrams (and plain GMF diagrams) should also be supported.<br />
<br />
We have not fully settled down on how to represent deletions on a diagram, but this otherwise begins to take form :<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0yoHf9kCYQqy4r_PVM44oB6Jzs_9mFgHB3F8MH7IdWNh3Y5Jn0a0V_eHa4ml0wq4pc908hFikv-fNvHykhxN-CvPuxJhU-lD1kFRq3wChF3YUnZBfoPPFznf2ufRDxps5I89_pgNQipMK/s1600/EMFC_Diagram_Compare.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="189" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0yoHf9kCYQqy4r_PVM44oB6Jzs_9mFgHB3F8MH7IdWNh3Y5Jn0a0V_eHa4ml0wq4pc908hFikv-fNvHykhxN-CvPuxJhU-lD1kFRq3wChF3YUnZBfoPPFznf2ufRDxps5I89_pgNQipMK/s320/EMFC_Diagram_Compare.png" width="320" /></a></div>
Do note that this is still very rough, and merging some of these differences (mainly "label changes") graphically is still problematic, but we expect this to be fine-tuned for Kepler's release :).<br />
<br />
Stay tuned!Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-67552866199591076392012-10-17T01:48:00.000-07:002012-10-17T01:48:15.416-07:00EMF Compare scalability - take twoExactly one year ago, I published here the results of the measuring and enhancing of <a href="http://eclipsemde.blogspot.fr/2011/10/emf-compare-scalability.html">EMF Compare 1.3 scalability</a> in which I detailed how we greatly improved the comparison times, and how we had observed that EMF Compare was a glutton in terms of memory usage. At the time, we did isolate a number of improvement axes... And they were part of what made us go forward to a new major version, EMF Compare 2.0.<br />
<br />
Now that <a href="http://eclipsemde.blogspot.fr/2012/09/emf-compare-2-is-available.html">2.0 is out of the oven</a>, and that we are rid of the 1.* stream limitations, it was time to move on to the next step and make sure we could <a href="http://www.eclipsecon.org/europe2012/sessions/emfcompare-20-scaling-millions">scale to millions</a>! We continued the work started last year as part of the <a href="http://wiki.eclipse.org/ModelingPlatform">modeling platform working group</a> on the support for <a href="http://eclipsemde.blogspot.fr/2011/06/whats-next-in-emf-compare.html">logical resources</a> in EMF Compare.<br />
<br />
The main problem was that EMF Compare needed to load two (or three, for comparisons with VCSs) times the whole logical model to compare. For large models, that quickly reached up to huge amount of required heap space. The idea was to be able to determine beforehand which of the fragments really needed to be loaded : if a model is composed of 1000 fragments, and only 3 out of this thousand have changed, it is a huge waste of time and memory to load the 997 others.<br />
<br />
To this end, we tried with EMF Compare 1.3 to make use of Eclipse Team's "logical model" APIs. This was promising (as shown in last year's post about our performances then), but limited since the good behavior of this API depends on the VCS providers to properly use them. In EMF Compare 2, we decided on circumventing this limitation by using our own implementation of a logical model support (see the <a href="http://wiki.eclipse.org/EMF_Compare/Logical_Model">wiki</a> for more on that).<br />
<br />
As a quick explanation, an EMF model can be seen as a set of elements referencing each other. This is what we call a "logical model" :<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://wiki.eclipse.org/images/0/05/Logical_Model.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://wiki.eclipse.org/images/0/05/Logical_Model.png" width="308" /></a></div>
However, these elements are not always living in memory. When they are serialized on disk, they may be saved into a single physical file, or they can be split across
multiple files, as long as the references between these files can be
resolved :<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://wiki.eclipse.org/images/6/6d/Logical_Model_Split.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://wiki.eclipse.org/images/6/6d/Logical_Model_Split.png" width="303" /></a></div>
If we remain at the file level, this logical model can be seen as a set of 7 files :<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://wiki.eclipse.org/images/6/66/EMFC_Logic_origin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://wiki.eclipse.org/images/6/66/EMFC_Logic_origin.png" /></a></div>
Now let's suppose that we are trying to compare a modified copy (<i>left</i>) of this model with a remote version (<i>right</i>). This requires a three-way comparison of left, right and their common ancestor, <i>origin</i>. That would mean loading all 21 files in memory in order to recompose the logical model. However, suppose that only some of these files really did change (blue-colored hereafter) :<br />
<table cellpadding="5" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://wiki.eclipse.org/images/9/90/EMFC_Logic_left.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://wiki.eclipse.org/images/9/90/EMFC_Logic_left.png" /></a></td><td style="text-align: center;"><a href="http://wiki.eclipse.org/images/1/11/EMFC_Logic_right.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://wiki.eclipse.org/images/1/11/EMFC_Logic_right.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><i>Left</i></td><td class="tr-caption" style="text-align: center;"><i>Right</i></td></tr>
</tbody></table>
In such a case, what we need to load is actually a small part of the 21 total files. For each three sides of the comparison, we only need to load the ones that can potentially show differences :<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://wiki.eclipse.org/images/b/bb/EMFC_Logic_loaded_fragments.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://wiki.eclipse.org/images/b/bb/EMFC_Logic_loaded_fragments.png" /></a></div>
Which means that we only need to load 9 out of the 21 files, for 58% less memory than what EMF Compare 1 needed (if we consider all files to be of equal "weight"). Just imagine if the whole logical model was composed of a thousand fragments instead of 7, allowing us to load only 9 files out of the total 3000!<br />
<br />
With these enhancements, we decided to run the very same tests as what we did last year with EMF Compare 1.3. Please take a look at my <a href="http://eclipsemde.blogspot.fr/2011/10/emf-compare-scalability.html">old post</a> for the three sample models' structure and the test modus operandi. I will only paste here as a reminder :<br />
<br />
The models' structure :<br />
<table border="0" cellspacing="0" cols="5" frame="VOID" rules="NONE"><tbody>
<tr><td align="LEFT" height="17" width="86"><br /></td><td align="LEFT" width="150"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-right: 1px solid #000000;"><br /></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Small</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Nominal</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Large</b></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Fragments</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">99</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">399</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">947</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Size on disk (MB)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1.37</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">8.56</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">49.9</td>
</tr>
<tr>
<td align="LEFT" height="1"></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Packages</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">97</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">389</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">880</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Classes</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">140</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">578</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">2,169</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Primitive Types</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">581</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5,370</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">17,152</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Data Types</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">599</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5,781</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">18,637</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">State Machines</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">55</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">209</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1,311</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">States</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">202</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">765</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">10,156</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Dependencies</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">235</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">2,522</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">8,681</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Transitions</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">798</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">3,106</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">49,805</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Operations</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1,183</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5,903</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">46,029</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Total element count</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">3,890</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">24,623</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">154,820</td>
</tr>
</tbody>
</table>
<br />
And the <b>Time and memory</b> used required to compare each of the model sizes with EMF Compare 1.3 :<br />
<table border="0" cellspacing="0" cols="5" frame="VOID" rules="NONE"><tbody>
<tr><td align="LEFT" height="17" width="86"><br /></td><td align="LEFT" width="150"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-right: 1px solid #000000;"><br /></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Small</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Nominal</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Large</b></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Time (seconds)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">6</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">22</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">125</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">maximum Heap (MB)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">555</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1,019</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">2,100</td>
</tr>
</tbody>
</table>
<br />
And without further ado, here is how these figures look like with EMF Compare 2.1 :<br />
<table border="0" cellspacing="0" cols="5" frame="VOID" rules="NONE"><tbody>
<tr><td align="LEFT" height="17" width="86"><br /></td><td align="LEFT" width="150"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-right: 1px solid #000000;"><br /></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Small</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Nominal</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Large</b></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Time (seconds)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">13</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">48</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">maximum Heap (MB)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">262</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">318</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">422</td>
</tr>
</tbody>
</table>
<br />
In short, EMF Compare now scales much more smoothly than it did with the 1.* stream, and it requires <b>a lot</b> less memory than it previously did. Furthermore, the one remaining time sink are the I/O and model parsing activities. The comparison in itself being reduced to only a few seconds.<br />
<br />
For those interested, you can find a much more detailed description of this work and the decomposition of the comparison process on <a href="http://wiki.eclipse.org/EMF_Compare/Logical_Model">the wiki</a>.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-65348395684186048392012-09-14T06:59:00.000-07:002012-09-14T07:00:53.604-07:00EMF Compare 2 is availableOn behalf of the team, I am very proud to announce that the 2.0 release of <a href="http://www.eclipse.org/emf/compare/">EMF Compare</a> is now available and can be downloaded from its <a href="http://download.eclipse.org/modeling/emf/compare/updates/releases/2.0">update site</a>. This release is compatible with Eclipse 3.5, 3.6, 3.7, 3.8 and 4.2.<br />
<br />
This new version is an overhaul of the project and as such contains too many enhancements to really list. You can refer to the <a href="http://www.eclipse.org/projects/project-plan.php?projectid=modeling.emf.compare#themes_and_priorities">project plan</a> for an overview of the major themes adressed by this new release, or to my <a href="http://eclipsemde.blogspot.fr/2012/08/emf-compare-20-on-launching-pad.html">previous post</a> for more information on why we decided to rewrite EMF Compare.<br />
<br />
API compatibility between the 1.3 and 2.0 releases is not assured. The new APIs provided with 2.0 were developed in order to be simpler and
more intuitive. A migration guide is not yet available, but we will provide all possible help in order to bridge the
gap between the two streams' APIs and help users migrate to the new and
improved Compare.<br />
<br />
Do not hesitate to drop by on the <a href="http://www.eclipse.org/forums/index.php/f/108/">forum</a> for any question regarding this release!Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com4tag:blogger.com,1999:blog-3658502096185788177.post-22547773551212659342012-08-02T04:38:00.001-07:002012-08-02T04:38:15.855-07:00EMF Compare 2.0 on the launching pad!This year has been a really important one for us at Obeo to think about our current products and how to improve them. Eclipse Juno was a big investment for us, with a lot of modeling projects in the release train : <a href="http://www.eclipse.org/acceleo/">Acceleo</a>, <a href="http://www.eclipse.org/emf/compare/">EMF Compare</a>, <a href="http://www.eclipse.org/modeling/emft/?project=eef">EEF</a>, <a href="http://www.eclipse.org/atl/">ATL</a>, <a href="http://www.eclipse.org/intent/">Mylyn Intent</a>...<br />
<br />
EMF Compare is the one that got us thinking the most, and we ended up developping <i>two versions in parallel</i> during the development phase of Juno. First is the version we actually included in the release train, <b>1.3.1</b>, which<b> is now the maintenance stream</b>.<br />
<br />
This version includes a number of new developments and enhancements. Most notably, the detection and merging of differences on values ordering has been greatly improved, and the merging in general was one of our major endeavors this year, fixing thousands of corner cases. Please refer to the <a href="http://wiki.eclipse.org/EMF_Compare/ReleaseReview/Juno#New_and_noteworthy">release highlights</a> for the noteworthy changes of this version.<br />
<br />
However, the 6 years of development spent on EMF Compare allowed us to identify a number of limitations in the architecture and overall design of the project, most of which cannot be worked around or re-designed without breaking the core of the comparison engine. We needed a <b>complete overhaul of the project</b>, and thus the second version we've been developping through the past year is the <b>2.0.0</b>.<br />
<br />
Version 2 has been started as part of the work sponsored in the context of the <a href="http://wiki.eclipse.org/ModelingPlatform">Modeling Platform Working Group</a>. Its two main objectives are to :<br />
<ul>
<li><b>lift the architectural and technical limitations of EMF Compare</b> so that we can reduce its memory footprint while improving its overall performance, and</li>
<li><b>simplify the API</b> we offer to our adopters so that launching comparisons or exploiting the difference model can be done more effectively.</li>
</ul>
We're also taking this opportunity to further our integration with the "standard" Eclipse Compare UI, making sure to use the Eclipse Compare UI everywhere we can. This means that the icon decorators will now properly show exactly as they would with text comparisons, the behavior when switching viewers on selection is now closer to what Eclipse Compare does...<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://img856.imageshack.us/img856/4599/emfcompare2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="150" src="http://img856.imageshack.us/img856/4599/emfcompare2.png" width="320" /></a></div>
<br />
Version 2.0.0 of EMF Compare will be out in the first half of august. It focuses on the comparison of models presenting IDs of some sort (XMI ID, technical ID, ...). The design and architecture have both been remasterized with all the experience accumulated on the 1.* stream, greatly improving the user experience, performance, memory footprint and reusability of the tool. We've submitted a talk for <a href="http://www.eclipsecon.org/europe2012/sessions/emfcompare-20-scaling-millions">Eclipse con Europe 2012</a> focussing on the intended improvements of this version. Do not hesitate to comment there if you're interested in it!<br />
<br />
<b>Version 2.1.0</b> is scheduled shortly after that, sometime during september. That new version will leverage the new architecture to provide the <b>scalability improvements mandatory for very large model comparisons</b>. In short, EMF
Compare will be able to function with time and memory footprints dependent on the number of
actual differences instead of being dependent on the input models' size.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-44428624616305482422012-01-20T06:04:00.000-08:002012-01-20T06:04:34.324-08:00Traceability test case : UML to Java generationThe next version of Acceleo will introduce a number of improvements of its existing features, one of its most important, the automatic builder, being entirely re-written in order to get rid of legacy code and improve the user experience. This also comes with a much better experience for users that need to build their Acceleo generators in standalone, through maven or tycho. More news on this are available on the <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=363651">bugzilla</a> and <a href="http://sbegaudeau.tumblr.com/post/16059815253/maven-integration-in-acceleo">Stephane's latest post</a>.<br />
<br />
One of the least visible features, yet one I find among the most interesting aspects of the Acceleo code generator, is the traceability between the generated code, the model used as input of the generation, and the generator itself. Basically, you always know where that esoteric line of code came from : which part of the generation template generated it, and which model element triggered its generation.<br />
<br />
This feature has known a series of improvements as we used it intensively with the <a href="http://marketplace.eclipse.org/content/uml-java-generator">UML to java generator</a>. We are now confident that we can record and display accurate information even for some of the most complex use cases. This generator isn't the most complex generator we could write with Acceleo, but it is quite complete nonetheless. Here are some examples of what the Traceability can provide to architects developping their code generators :<br />
<br />
<b>Determine which model element triggered the generation of a line of code</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
On the left-hand side, a file that has been generated. On the right-hand side, an editor opened as result of using the action "open input" : the model is opened and the exact element that was used to generate the part of code is selected.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhf1Ij_D64vd1xyVoIb5MvjtiVWDhMmYNnl9QespNXDwGLsOAgLvgFhVgljKP-ZuU7YWI5ji2himu3qBIfDi9ttWz8esCGwXjYSQFSEsxNmh7m6eefRrWEPPNgHsqfXfr3r8dRAmgftozxV/s1600/OpenInput.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="216" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhf1Ij_D64vd1xyVoIb5MvjtiVWDhMmYNnl9QespNXDwGLsOAgLvgFhVgljKP-ZuU7YWI5ji2himu3qBIfDi9ttWz8esCGwXjYSQFSEsxNmh7m6eefRrWEPPNgHsqfXfr3r8dRAmgftozxV/s320/OpenInput.jpg" width="320" /></a></div>
<br />
<b>Find the part of a generator that created a given part of the code</b><br />
<br />
On the left-hand side, the same generated file as above. On the right-hand side, the result of using the "open generator" action : the Acceleo generator which generated that selected part of the code is opened, with the exact source expression selected.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMNc337cdNhqjN3dLRvHDxE8fbvw0BA3PDzkXxLew19qlxWeokabYOtgdETlMd2GhIYijrU7ZvTPL_V-LbVH8nrZFqYFWu-qE8b9ctAk3hWYjIXzOG4MSyeNCf0jlka0gCOYgh-9bfQDcP/s1600/OpenGenerator.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="216" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMNc337cdNhqjN3dLRvHDxE8fbvw0BA3PDzkXxLew19qlxWeokabYOtgdETlMd2GhIYijrU7ZvTPL_V-LbVH8nrZFqYFWu-qE8b9ctAk3hWYjIXzOG4MSyeNCf0jlka0gCOYgh-9bfQDcP/s320/OpenGenerator.jpg" width="320" /></a></div>
<br />
<b>Real-time Synchronization</b><br />
<br />
<iframe allowfullscreen="" frameborder="0" height="480" src="https://www.youtube.com/embed/SZEPgrFPj-0?rel=0" width="640"></iframe><br />
<br />
These are but a few of the features that can be derived from the synchronization between code, model, and generators. Some more examples include : previewing the result of a re-generation, incremental generation, round-trip (updating the input model according to manual changes in the output generated code)...<br />
<br />
Most of these features are better seen in video to get an idea. If you want to see some of them in action, some more flash videos of what traceability can do for you are available on the <a href="http://www.obeonetwork.com/page/obeo-traceability">Obeo network</a> (though a free registration is required).Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com4tag:blogger.com,1999:blog-3658502096185788177.post-84625279394718081622011-10-27T09:40:00.000-07:002011-10-27T09:40:28.196-07:00EMF Compare scalabilityDuring the sponsored work on EMF Compare, we have taken some time to measure the performance of EMF Compare and think about possible improvement axis. We meant to profile both the time needed to compare two models and the overall memory footprint of a comparison, this has been achieved through the use of the <a href="http://www.yourkit.com/download/index.jsp">Yourkit Java profiler</a>.<br />
<br />
The first measures we took highlighted such a huge kludge that we took the time to better the comparison algorithms before taking any further action. Through the use of google's <a href="http://code.google.com/p/guava-libraries/">Guava</a> and some rethinking, we improved the comparison time on big model comparison a great deal, dividing the total comparison time in half!<br />
<br />
Here is a sample of the time it takes now to compare your models with the latest builds of EMF Compare :<br />
<br />
<b>Structure of the sample models</b> used in these tests ("fragments" are the number of fragmented files, the rest are UML model elements contained by the samples) :<br />
<table border="0" cellspacing="0" cols="5" frame="VOID" rules="NONE"><tbody>
<tr><td align="LEFT" height="17" width="86"><br /></td><td align="LEFT" width="104"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-right: 1px solid #000000;"><br /></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Small</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Nominal</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Large</b></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Fragments</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">99</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">399</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">947</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Packages</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">97</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">389</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">880</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Classes</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">140</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">578</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">2169</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Primitive Types</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">581</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5370</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">17152</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Data Types</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">599</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5781</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">18637</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">State Machines</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">55</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">209</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1311</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">States</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">202</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">765</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">10156</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Dependencies</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">235</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">2522</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">8681</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Transitions</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">798</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">3106</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">49805</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Operations</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1183</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">5903</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">46029</td>
</tr>
</tbody>
</table>
<br />
<b>Time and memory</b> used required to compare each of the model sizes (the model is copied, randomly modified, then the copy is compared with its original) :<br />
<table border="0" cellspacing="0" cols="5" frame="VOID" rules="NONE"><tbody>
<tr><td align="LEFT" height="17" width="86"><br /></td><td align="LEFT" width="150"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
<td align="LEFT" width="86"><br /></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-right: 1px solid #000000;"><br /></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Small</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Nominal</b></td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;"><b>Large</b></td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">Time (seconds)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">6</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">22</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">125</td>
</tr>
<tr>
<td align="LEFT" height="17"><br /></td>
<td align="LEFT" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">maximum Heap (Mo)</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">555</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">1019</td>
<td align="CENTER" style="border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: 1px solid #000000; border-top: 1px solid #000000;">2100</td>
</tr>
</tbody>
</table>
<br />
We initially thought that the time was mostly spent matching the elements together. It turns out that the real bottleneck of a comparison is the differencing phase (we know the two elements "match", now we need to know if, and how they differ). Just goes to show you that a profiler is mandatory in order to really <i>know</i> why your product might be slow ;).<br />
<br />
<b>Future development</b><br />
<br />
These profiling sessions made clear the problems of EMF Compare on large models. We can properly handle "medium" models : EMF Compare is fast and its GUI can react at reasonable speed. However we cannot scale this behavior to large models : memory management is somewhat inefficient (more than 2Go of heap space to compare two models that both "weigh" 50Mo on disk...), the GUI is sluggish... We did isolate a number of potential improvements though. Stay tuned!<br />
<br />
Note : the report is online and can be retrieved from <a href="http://www.eclipse.org/emf/compare/doc/compare_scalability.pdf">here</a> for those interested.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-43527781792316049752011-09-28T06:10:00.000-07:002011-09-28T06:14:54.020-07:00The dynamic interpreter, your code generation companionThe latest stable release of Acceleo, version 3.1.1 included in Indigo SR1, is fresh from the oven; but development on the next version is already well underway. The upcoming version 3.2 already includes major improvements of the tooling performance (compilation time, completion proposal computation, memory management...), making the everyday use of the Acceleo editor much more appealing; and some of the planned features for this version are already in their finalization stage.<br />
<br />
The one feature I'll linger on here is the dynamic interpreter for Acceleo and OCL expressions that we implemented for this version. Typically, you develop your code generators within the Acceleo editor, making use of the advanced edition features such as completion proposals, live compilation and syntax error reporting, syntax highlighting ...<br />
<br />
However the editor itself cannot help you determine what a given expression will return as its result. When you are in the middle of a complex OCL expression, it is sometimes difficult to say "this expression will output that classifier". And here is where the live interpreter comes into play!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjzPP51sn57HOlDjyHallbPEs9yVvae_rVstX75CKtccfZmMiFgi_IDz0U3MOZ_OQw4S6ac3jqcWjPGKwY4UX_2dLvhWl2C3joAeK12wIU8Xmof9Y8c97MJfKl8NXY1Qv_7nilcwcLr2O_/s1600/Class_supertypes.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="267" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjzPP51sn57HOlDjyHallbPEs9yVvae_rVstX75CKtccfZmMiFgi_IDz0U3MOZ_OQw4S6ac3jqcWjPGKwY4UX_2dLvhWl2C3joAeK12wIU8Xmof9Y8c97MJfKl8NXY1Qv_7nilcwcLr2O_/s320/Class_supertypes.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
The image above displays the "interpreter" view and the use we can make of it : We opened the UML metamodel and selected "Class" in it. This makes "Class" the context of any evaluation entered in the interpreter (that would work with anything that can be adapted to an EMF object : selection in a model editor, selection in a graphical editor (GMF, Obeo Designer... even the "variable" view when debugging Acceleo generations!). We entered an expression... and the view made the rest, evaluating that expression on-the fly and displaying its result (here, all of the super-types of the UML "Class").<br />
<br />
<b>Using the Interpreter during debug</b> <br />
<br />
The Interpreter can be used as is, defining your own variables as you need them and entering the expression manually... but it can also be used in conjunction with the debugger. For example, let's say I want to know what happens within the 'UML 2 Java' example that is provided with Acceleo.<br />
<ul>
<li>I open the "classBody" module of that example, and set a breakpoint somewhere within the "generateClassBody" template :</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1MhnqxnZZBaWqAW5Y5B6AR215KA53qsAgMY30EYyJlCs-vDbD0xbBswJgAktOm6SKPAEsBl8dJRsxFx22GmoX7Lp4M-UWhNWX9mORCoZUolbkn9IoeGrumaoJMTFaP0v5_6BirMcPew6c/s1600/module_breakpoint.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="204" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1MhnqxnZZBaWqAW5Y5B6AR215KA53qsAgMY30EYyJlCs-vDbD0xbBswJgAktOm6SKPAEsBl8dJRsxFx22GmoX7Lp4M-UWhNWX9mORCoZUolbkn9IoeGrumaoJMTFaP0v5_6BirMcPew6c/s320/module_breakpoint.png" width="320" /></a></div>
<ul>
<li>Then, run the example in debug mode until the breakpoint is hit :</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgT3ezfniFSuFqSORfQigQcyCUSG2aIV4-D8v_cxDmvvdbmfLEk5lT5UnKjYDEhyphenhyphenL53OQw1QgKzqMouP8SnxXfYImuS7sXsxFeyNTZMOmxBKOdVvcJRbxi-MvsjS0r9yiJ4ozUME0DRSlF/s1600/module_breakpoint_hit.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="147" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgT3ezfniFSuFqSORfQigQcyCUSG2aIV4-D8v_cxDmvvdbmfLEk5lT5UnKjYDEhyphenhyphenL53OQw1QgKzqMouP8SnxXfYImuS7sXsxFeyNTZMOmxBKOdVvcJRbxi-MvsjS0r9yiJ4ozUME0DRSlF/s320/module_breakpoint_hit.png" width="320" /></a></div>
<ul>
<li>And from there, I can either copy/paste whole expressions in the interpreter :</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqSAhWUOimvFGojk3BGFTn0kDP1NubViPDjMFzsMH3Snwnxqo_hfXsJnvmFlBAGaofiDJTUHImWM4qk6dgeKGMt8S1oILDgSYAJSXa8vQgyg4Fu4FcQrR4ln5EMjP6Ojz0eZfMrAeDRrur/s1600/interpreter_debug_copypaste.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="89" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqSAhWUOimvFGojk3BGFTn0kDP1NubViPDjMFzsMH3Snwnxqo_hfXsJnvmFlBAGaofiDJTUHImWM4qk6dgeKGMt8S1oILDgSYAJSXa8vQgyg4Fu4FcQrR4ln5EMjP6Ojz0eZfMrAeDRrur/s320/interpreter_debug_copypaste.png" width="320" /></a></div>
<ul>
<li>Or "link" the interpreter with the current module context...</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYSK9HqUPDr3h57X6i-wOJnXv4xDhh4lUsTc3KFG9nwvGJIwtP7Q4eRZvq_UOYgpA0Ge7AUYSt6NpfUTkGHJ9AZ2BiB8ZTnjGpRTZZTU2Bx4bO8OmAZUxHWXf4iXwffLUouHPxyG_UCq53/s1600/interpreter_debug_link_action.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="34" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYSK9HqUPDr3h57X6i-wOJnXv4xDhh4lUsTc3KFG9nwvGJIwtP7Q4eRZvq_UOYgpA0Ge7AUYSt6NpfUTkGHJ9AZ2BiB8ZTnjGpRTZZTU2Bx4bO8OmAZUxHWXf4iXwffLUouHPxyG_UCq53/s320/interpreter_debug_link_action.png" width="320" /></a></div>
<ul>
<li>And directly call its templates : </li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigrcZdfDsAl5sNipXXsd4xoTgmPRvnf818Q46BOJmbdjsQlWh1_Vn7ePxqD33kGVXlbjTtk8lEemfuhslgiD3IMQPiHVEQDVqMDVpDnbBHIR9SQUkyS4s5FTKqoiV20P6v7NfZzFSOqiJk/s1600/interpreter_debug_link.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="89" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigrcZdfDsAl5sNipXXsd4xoTgmPRvnf818Q46BOJmbdjsQlWh1_Vn7ePxqD33kGVXlbjTtk8lEemfuhslgiD3IMQPiHVEQDVqMDVpDnbBHIR9SQUkyS4s5FTKqoiV20P6v7NfZzFSOqiJk/s320/interpreter_debug_link.png" width="320" /></a></div>
<ul>
<li>Of course, the result of this last action is lengthier than a single line, double clicking the result will open a popup in which it will be more readable :</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP75Cjd5UGjcsbwSah309WmIVj8P0UMhvwgBpflGuadZlFW7RwKCcrDcteTpFejk1ndugZu12lBTTCgQach45E3uPYE-GogXkOIfZcPWTXtEGs1exaj3Tam2fhJo-zltPnIDw-oYSqxWW2/s1600/interpreter_debug_link_result.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="303" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjP75Cjd5UGjcsbwSah309WmIVj8P0UMhvwgBpflGuadZlFW7RwKCcrDcteTpFejk1ndugZu12lBTTCgQach45E3uPYE-GogXkOIfZcPWTXtEGs1exaj3Tam2fhJo-zltPnIDw-oYSqxWW2/s320/interpreter_debug_link_result.png" width="320" /></a></div>
<br />
The view features a number of possibilities, creating and assigning variables to be used in the expression, real-time evaluation, linking with an Acceleo editor's context, saving the expression as a new query or template in a given Acceleo module... The view itself can be used without Acceleo, and accepts any other languages through extension points. I can't detail all of its features and extension possibilities here, see the <a href="http://wiki.eclipse.org/Acceleo/Interpreter">wiki page</a> for more (still a work in progress, yet it does describe the view in little more details than here) :).Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-80132321313076467392011-08-09T04:55:00.000-07:002011-08-09T05:30:25.452-07:00EMF Compare - giant steps towards a working mergerEMF Compare, or how to provide meaningful comparison algorithms and visualization for models. Comparing the models' XMI serializations as text is a chore that we should never have to go back to, and EMF Compare has always strived at doing the best possible job towards that end.
<br />
<br />Who would rather compare their models textually :
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4IFVxu2G7NTsp9xhgRXoVR_RBTB6gPFAePP1QPWzOjvdkBiYuRczuGyQGwiySlzKjSZ2HBkYA9vRZGkdKf7tu0xCCvulK75m3n06ee5n25A_U37nNyu0vaNqubSEQ2wlE98L9MW2Ujoyc/s1600/text_compare.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 85px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4IFVxu2G7NTsp9xhgRXoVR_RBTB6gPFAePP1QPWzOjvdkBiYuRczuGyQGwiySlzKjSZ2HBkYA9vRZGkdKf7tu0xCCvulK75m3n06ee5n25A_U37nNyu0vaNqubSEQ2wlE98L9MW2Ujoyc/s320/text_compare.png" alt="" id="BLOGGER_PHOTO_ID_5638828660517512370" border="0" /></a>
<br />Than compare them logically (yes, these are the same models as above) :
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHLnVZ2wvkSXQz0_rApXXlgYycEk4b9ljo9L2CDsobEq2gjE6EaPbA_m-9KrgSLtZuw-Lq6tD5T3MhR_LVoBisK_9Ok4zH8o1zmszpqtNORtOdWP-LAuKPb3RxhEoASdzvxHQI8bdJgzqM/s1600/model_compare.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 105px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHLnVZ2wvkSXQz0_rApXXlgYycEk4b9ljo9L2CDsobEq2gjE6EaPbA_m-9KrgSLtZuw-Lq6tD5T3MhR_LVoBisK_9Ok4zH8o1zmszpqtNORtOdWP-LAuKPb3RxhEoASdzvxHQI8bdJgzqM/s320/model_compare.png" alt="" id="BLOGGER_PHOTO_ID_5638828664645311986" border="0" /></a>
<br />However, EMF Compare still had issues with most algorithm : small errors when matching elements together, differences that weren't detected ... and worst of all : merging all diffs from one side to the other rarely gave the expected result of "two identical models", i.e : if the comparison process in itself was working fairly well, we had a huge number of failures when merging.
<br />
<br />We've decided to tackle this problem the way we should have from the very start : list all potential differences that can be observed between two models ... and <span style="font-weight: bold;">create the corresponding unit test</span>!
<br />
<br />The results are already showing. True, we are still missing a number of unit tests in order to test all potential use cases we can list ... but we've already fixed an incredible number of bugs be they known (half of our opened bugs, forty-ish out of eighty or so) or bugs we had never detected before. The number of unit tests talks for itself :
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyixxc4JHIQ2U576kBb5Y_c94hM0K4ewETCvckaXrEjPIfo9CAhV-IWeNI47wWukrkFTuFIThpRqKufzQF7-A2c3EiBjE36IAveMM6XKOX0bEabSsFd5lvskggAhvfyFv_pRxbmCLnXRK5/s1600/test_result_trend.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 154px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyixxc4JHIQ2U576kBb5Y_c94hM0K4ewETCvckaXrEjPIfo9CAhV-IWeNI47wWukrkFTuFIThpRqKufzQF7-A2c3EiBjE36IAveMM6XKOX0bEabSsFd5lvskggAhvfyFv_pRxbmCLnXRK5/s320/test_result_trend.png" alt="" id="BLOGGER_PHOTO_ID_5638830598968694754" border="0" /></a>
<br />That's 4000 unit tests and as many different combinations of differences added and fixed in the past weeks.
<br />
<br />I won't lie, some of these tests are redundant because of the way we decided to work : we are not trying to cover code, but rather cover use cases; which means some of these tests overlap with others. This does mean, however, that we are fairly sure we'll never have regressions on things that are tested :).
<br />
<br />And now, back to the last few tests we are still missing!
<br />Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-40133599686742305862011-06-16T02:10:00.000-07:002011-06-26T00:47:46.412-07:00What's next in EMF Compare<a href="http://www.eclipse.org/indigo/">Indigo</a> is now out and about; another great release shipped on time. I am always amazed that the Eclipse community manages to release each year on schedule. Congratulations to all that help make it happen!<br /><br />EMF Compare 1.2.0 was part of the train again this year, I recently blogged about the <a href="http://eclipsemde.blogspot.com/2011/06/whats-new-in-emf-compare.html">new and noteworthy</a> of that release. Now that the train has arrived, we can think of what to do next... and it looks like a busy year is coming EMF Compare! Further integration with the Team framework, graphical comparison...<br /><br />Here is a quick peek of what EMF Compare could look like for Eclipse Juno next year :<br /><br /><span style="font-weight: bold;">Logical Resources support</span><br /><br />Up until now, we've considered that EMF models were tied to physical files, one EMF Resource being one File on the disk. That is true in some cases ... but in many others, a "model" is not really a "file". One file holding an EMF Resource (let's call it "library") can reference multiple other EMF Resources ("books" and "writers"), and it can even be split into multiple physical files itself.<br /><br />If we call EMF models "logical resources" and their files on disk "physical resources", we thus distinguish two cases for EMF Compare : 1) one logical resource mapped to one physical resource (no reference, no fragments) and 2) one logical resource mapped to multiple physical resources (an EMF model that references others, and/or is fragmented). Only the first of these two cases is properly handled for now; we've only scratched the surface of the second and handled the most common cases.<br /><br />Eclipse provides us with a framework to work on logical resources and resource mappings. We've decided to take advantage of these APIs for the case of collaborative work on EMF models. The idea is to make sure that the user never ends up with a corrupt logical model by preventing him from doing anything on a single part of the physical resources' set (or warning him when he does so).<br /><br />For example, if an EMF model "library.genmodel" references another EMF model "library.ecore", and there are changes in both (the name of an EClass changed, and so did the corresponding GenClass in order to react to that name change), it should never be allowed to the user to commit <u>only</u> one of those two files : they are part of the same logical model, commiting only one of the two physical files may corrupt the logical model (which is the case in this example). The same applies to comparing either one of the physical files with the repository : as they are part of a set, the whole set should be used when comparing.<br /><br />This support is already implemented and functional with CVS; the EGit plugin does not yet use the necessary APIs, yet support is on its way and should be gradually implemented on the way to Juno.<br /><br />As a result, here is what you would get with the current EMF Compare when trying to commit such linked files to CVS HEAD :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFR16khzIERtWU3jJkMN6TwFURUNdqBqnrR1fSWnns97ZDhZfOc8F3e2lExzEgOTrcVWrH6q3ncTr-KGYYr3mzcFiN5zEsh4Z1rRYmH646HLcbq-61nPmSsSWEmWi62ANLPRj6CEyoc8Zz/s1600/before_commit_action.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 63px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFR16khzIERtWU3jJkMN6TwFURUNdqBqnrR1fSWnns97ZDhZfOc8F3e2lExzEgOTrcVWrH6q3ncTr-KGYYr3mzcFiN5zEsh4Z1rRYmH646HLcbq-61nPmSsSWEmWi62ANLPRj6CEyoc8Zz/s320/before_commit_action.png" alt="" id="BLOGGER_PHOTO_ID_5618808704522239394" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOqAUqdh2bNjqw3q9RS1DQpc-OhOrZCJlz-5SgOgQpBz7LOHnxjFrSwUt2okHJuh-Gl9OFKogPpoz3LOSXcONY1QWyj40GIGlQJaK6D5ShAbZu6TuWNHHLQ28bxf7s6m851NBY0z3GGzoq/s1600/before_commit_dialog.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 276px; height: 320px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOqAUqdh2bNjqw3q9RS1DQpc-OhOrZCJlz-5SgOgQpBz7LOHnxjFrSwUt2okHJuh-Gl9OFKogPpoz3LOSXcONY1QWyj40GIGlQJaK6D5ShAbZu6TuWNHHLQ28bxf7s6m851NBY0z3GGzoq/s320/before_commit_dialog.png" alt="" id="BLOGGER_PHOTO_ID_5618808710844946578" border="0" /></a><br />In other words, you are allowed to commit the genmodel file alone... which will prevent anyone retrieving that version from opening it from their side as it references a Class that does not exist without the change to "library.ecore". On the contrary, here is the same flow of action with the logical resources support :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMHpL4WzZu7-nI7mNRk1q9O-oE3GwFdyoX1ThBklUqEVnop8N0d2UqHUTcKBkjYQt1Ad8U-FKvSvS26NcZpssr8EFltlMhznbd6vO0PcL2tywD-Xyi6JeJ-xkt1gRxvGLeFR__GDJxAqCO/s1600/after_commit_action.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 63px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMHpL4WzZu7-nI7mNRk1q9O-oE3GwFdyoX1ThBklUqEVnop8N0d2UqHUTcKBkjYQt1Ad8U-FKvSvS26NcZpssr8EFltlMhznbd6vO0PcL2tywD-Xyi6JeJ-xkt1gRxvGLeFR__GDJxAqCO/s320/after_commit_action.png" alt="" id="BLOGGER_PHOTO_ID_5618811485899554178" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOiiQJast0le-1-7a0Gyor_h8qMKKAnwE5rVQs4iE3slaSLNWq-J5jt2z6PNVrr3FongmCgsgRScvlmVKjZn093PzfgDLvw4zGfPgDmpIfEcysD8d9wUVYk225sLwiN0vPFSCwlPgh_hvA/s1600/after_commit_validate.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 290px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOiiQJast0le-1-7a0Gyor_h8qMKKAnwE5rVQs4iE3slaSLNWq-J5jt2z6PNVrr3FongmCgsgRScvlmVKjZn093PzfgDLvw4zGfPgDmpIfEcysD8d9wUVYk225sLwiN0vPFSCwlPgh_hvA/s320/after_commit_validate.png" alt="" id="BLOGGER_PHOTO_ID_5618811491250022706" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOsYy0TgTn5I_Nz-N915qHQJ6NbgvgEmaxUrTI0RvSLU2NWgMdxoPfyu_PM1jTT651cK9txKnBRmP03VTMUVqTLEAXBtkuIY-lZCL-5HBwrRNImu9iR7msNmc5DOeusvyvyvFwByjYpw6v/s1600/after_commit_dialog.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 276px; height: 320px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOsYy0TgTn5I_Nz-N915qHQJ6NbgvgEmaxUrTI0RvSLU2NWgMdxoPfyu_PM1jTT651cK9txKnBRmP03VTMUVqTLEAXBtkuIY-lZCL-5HBwrRNImu9iR7msNmc5DOeusvyvyvFwByjYpw6v/s320/after_commit_dialog.png" alt="" id="BLOGGER_PHOTO_ID_5618811483795146674" border="0" /></a><br />Here, even though we tried to commit "library.genmodel", Eclipse forces us to commit "library.ecore" along with it in order not to corrupt the logical model underneath.<br /><br /><span style="font-weight: bold;">Diagram comparison</span><br /><br />EMF Compare supports comparison and merging of any kind of EMF model. It then displays the differences in a the form of two trees side by side as illustrated below :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhB9ChzPQbwxH6FQGH8-W0eskkxkviqJBXwAp5-n0shMT1-v8W7Vf5DV5E3p99K-zp36ww_MCsX7ykAEJQeu9rAQpuneGHaljlhtGjQdyT_4Od1fGDNF_WM6tM-mSVA8c0etl62pJmj7a2V/s1600/emf_compare.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 208px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhB9ChzPQbwxH6FQGH8-W0eskkxkviqJBXwAp5-n0shMT1-v8W7Vf5DV5E3p99K-zp36ww_MCsX7ykAEJQeu9rAQpuneGHaljlhtGjQdyT_4Od1fGDNF_WM6tM-mSVA8c0etl62pJmj7a2V/s320/emf_compare.png" alt="" id="BLOGGER_PHOTO_ID_5618819306607608834" border="0" /></a><br />The tree form, however, is not the most adapted representation for all models. When comparing GMF diagrams for example, it would be interesting to display the detected differences directly on the diagram itself :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkkqhSP2HppOfLLvUHtKWq7iy33c7wa9fOZKR4FZafrPZNd7ENeYgyhbxHTnpplroYVNDyOt_uTBRb88Cz6hR0fkkTqkVzfcHa6ZjLs_FiDkkMgnTEDQ8f9p3NY3OzZVmLl21qyPLzqFXr/s1600/Diag_comp_diff.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 236px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkkqhSP2HppOfLLvUHtKWq7iy33c7wa9fOZKR4FZafrPZNd7ENeYgyhbxHTnpplroYVNDyOt_uTBRb88Cz6hR0fkkTqkVzfcHa6ZjLs_FiDkkMgnTEDQ8f9p3NY3OzZVmLl21qyPLzqFXr/s320/Diag_comp_diff.png" alt="" id="BLOGGER_PHOTO_ID_5618820416615843698" border="0" /></a><br />Support for this graphical representation of the differences is planned for the end of the year. More information regarding this feature (and specifications of what we intend to implement) can be found on the <a href="http://wiki.eclipse.org/EMF_Compare/GMF_Compare_Markers">EMF Compare wiki</a>.<br /><br /><span style="font-weight: bold;">UML Compare</span><br /><br />We have faced since the first version of EMF Compare a number of problems when comparing UML files; problems that just could not be properly handled by the generic approach we take for the comparison.<br /><br />Most of these problems come from the fact that a "semantic" change in UML is often reflected by a number of "physical" changes in the model. For example, adding an association between two classes results (with the Papyrus) in two actual changes in the model :<br /><ul><li>a new element is added (the Association)</li><li>a new Property is added to the target class<br /></li></ul>With the Indigo release, we integrated the first version of an UML-specific comparison engine in order to properly detect (and display) the semantic level differences instead of the previous 'physical level' differences.<br /><br />This first implementation will be greatly improved so as to handle the most common UML diagrams (class, package, use case, sequence... the full list can be found on <a href="http://wiki.eclipse.org/EMF_Compare/UML_Compare">the wiki page</a>), for all potential changes that can be applied in them.<br /><br />For example, the Indigo version of the UML comparison engine does not handle specifically message additions, which thus result in seven differences detected :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTlHQbUrj5dewm4BgjYAw7mkJmtAU2f2vt2uU_A2tl5X1CYAHGd_ZscLf8S0vyM4ErL3go7Qte-Z9reKKH2FnU4Yq3EWeKYGS80WpozlPPvOxrE4KI6mqLvmRPaEt3Haqk0FpccFHvOg-H/s1600/Message-generic.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 242px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTlHQbUrj5dewm4BgjYAw7mkJmtAU2f2vt2uU_A2tl5X1CYAHGd_ZscLf8S0vyM4ErL3go7Qte-Z9reKKH2FnU4Yq3EWeKYGS80WpozlPPvOxrE4KI6mqLvmRPaEt3Haqk0FpccFHvOg-H/s320/Message-generic.png" alt="" id="BLOGGER_PHOTO_ID_5618827592083723474" border="0" /></a><br />While the current implementation (which will be available for the Indigo SR1 release later this year) properly handles them and displays a single change :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivtP-GI2hebCuN3Gsb6pb_UIpaxRT1n-4g-dQJZtuEz049Bib4445YZ_6DcGozKmg4CiB9FHqTi5YTdieppXBd31PFWW4P-mH9Lz72qUzU8N4g5v65z2CkTnd9rLYgKciXql-P5mH16so2/s1600/Message-uml2.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 198px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivtP-GI2hebCuN3Gsb6pb_UIpaxRT1n-4g-dQJZtuEz049Bib4445YZ_6DcGozKmg4CiB9FHqTi5YTdieppXBd31PFWW4P-mH9Lz72qUzU8N4g5v65z2CkTnd9rLYgKciXql-P5mH16so2/s320/Message-uml2.png" alt="" id="BLOGGER_PHOTO_ID_5618827593914962114" border="0" /></a><br /><br />Indigo is out, time to move on to these exciting new features... Well, almost :). For now, 'tis time to relax a little bit. Sun, beach and beer seem like a perfect combination to that end :).<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhacfGe3ZDr4nN1l6m8xdpRmgfJz9oyC-V9T5_CY75Z8jdSu1QYlB_eEB2zh4ZjE3SAZAmFxywxkcpsjeDahqmeN5tGk9U1JbIMv8Y3UsBZJXPd1TzVB6hYdXismvdlIGCMNmPQIkNBLGMs/s640/Aleria.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 640px; height: 499px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhacfGe3ZDr4nN1l6m8xdpRmgfJz9oyC-V9T5_CY75Z8jdSu1QYlB_eEB2zh4ZjE3SAZAmFxywxkcpsjeDahqmeN5tGk9U1JbIMv8Y3UsBZJXPd1TzVB6hYdXismvdlIGCMNmPQIkNBLGMs/s640/Aleria.jpg" alt="" border="0" /></a>Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-6498290649864913442011-06-16T00:43:00.000-07:002011-06-16T02:47:13.189-07:00What's new in EMF CompareHere we are again, it is almost time for the annual Eclipse release; this year for the sixth consecutive named simultaneous release. EMF Compare has been there since Callisto, the first of those six; and <a href="http://www.eclipse.org/emf/compare/">EMF Compare</a> 1.2.0 is now on its way out. So, what has been added to this new release?<br /><br />Among the usual bug fixes, we have added some noteworthy features :<br /><br /><span style="font-weight: bold;">Difference grouping</span><br /><br />EMF Compare can detect a number of differences between models; additions, deletions, moves... It is now possible to "group" these changes by type in order to read the comparison with a little more ease.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYny39rKnBqGc9WzciW8mz1wrNSTyjv6c88cTEEXNDRCzkXuARF7kg3rHhNuPj-m1oadYbiLMzcmGedmicrKpjXiyyTOSkDWmptSXNieSn4KKpNsobgNrPkYIjEcTt4aJZZsiZ9aMslHg8/s1600/Grouping_Default.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 67px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYny39rKnBqGc9WzciW8mz1wrNSTyjv6c88cTEEXNDRCzkXuARF7kg3rHhNuPj-m1oadYbiLMzcmGedmicrKpjXiyyTOSkDWmptSXNieSn4KKpNsobgNrPkYIjEcTt4aJZZsiZ9aMslHg8/s320/Grouping_Default.png" alt="" id="BLOGGER_PHOTO_ID_5618728823939383426" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkcypHyP4kaoeTtuUukVXly1prPMDgjIsT64R5uFkdppRPSHz79_18Jd6UYnUM8S-UV56hxBPb8_B3QcKTDlAPe3LT6rYBPtOQn6fMCSaj9dmKKWDIREKjcl_u1liCbG1EuRGOKlriCTpb/s1600/Grouping_Kind.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 66px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkcypHyP4kaoeTtuUukVXly1prPMDgjIsT64R5uFkdppRPSHz79_18Jd6UYnUM8S-UV56hxBPb8_B3QcKTDlAPe3LT6rYBPtOQn6fMCSaj9dmKKWDIREKjcl_u1liCbG1EuRGOKlriCTpb/s320/Grouping_Kind.png" alt="" id="BLOGGER_PHOTO_ID_5618728827178970498" border="0" /></a><br />New Grouping strategies can also easily be contributed by client plugins; more information can be found on <a href="http://wiki.eclipse.org/EMF_Compare/Grouping_facility">the dedicated wiki page</a>.<br /><br /><span style="font-weight: bold;">Difference filtering</span><br /><br />It is now possible to filter out some of the differences from the EMF Compare UI. For example, here is the same comparison as above without the "added" elements :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmqeLfFV7zuwhWYtQJKxcBinQnaLsg-yAfUYd4wGDOrqA6UsTmzS6St22bLjnCv6JrFmSWylk7FMq5hxKPeCzp-ZizvgXTisp1iBd20atYDVEaZNotzQCSBhVIdn2xWkNNvh_-kNicD8q8/s1600/Filtering.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 71px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmqeLfFV7zuwhWYtQJKxcBinQnaLsg-yAfUYd4wGDOrqA6UsTmzS6St22bLjnCv6JrFmSWylk7FMq5hxKPeCzp-ZizvgXTisp1iBd20atYDVEaZNotzQCSBhVIdn2xWkNNvh_-kNicD8q8/s320/Filtering.png" alt="" id="BLOGGER_PHOTO_ID_5618730333339826434" border="0" /></a><br />As for grouping, new filtering strategies can be contributed by clients plugins. Detailled information on this feature can be found on <a href="http://wiki.eclipse.org/EMF_Compare/Filtering_facility">the wiki</a>.<br /><br /><span style="font-weight: bold;">Textual comparison of attribute values</span><br /><br />If a change in an attribute value has been detected by EMF Compare, it will display, by default, a message such as "attribute <attributename> : <attributetype> in class <classname> has changed from <oldvalue> to <newvalue>". This message is hardly readable for long "string" values of attributes. EMF Compare now allows you to get a dialog displaying the textual comparison of those values :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmE_uSmIsmYFoos0vaKLeeQPlBvgACci_ozXx3V8RjfdZWBKDJ3rUL-LAfbvUC7jsBiz9-wtUKNR9DXm-A-Hd-svi4Rc4Ki8vvkJD2c5cUOiXz8E8NrAY2yNK3jDqzmWkFyfaA8i4VbfzX/s1600/2way-textcomp.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 222px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmE_uSmIsmYFoos0vaKLeeQPlBvgACci_ozXx3V8RjfdZWBKDJ3rUL-LAfbvUC7jsBiz9-wtUKNR9DXm-A-Hd-svi4Rc4Ki8vvkJD2c5cUOiXz8E8NrAY2yNK3jDqzmWkFyfaA8i4VbfzX/s320/2way-textcomp.png" alt="" id="BLOGGER_PHOTO_ID_5618733471040229202" border="0" /></a><br />As usual, detailled information can be located on <a href="http://wiki.eclipse.org/EMF_Compare/Textual_diff_in_model_diff">the corresponding wiki page</a>.<br /><br /><span style="font-weight: bold;">UML-specific comparison engine</span><br /><br />EMF Compare provides a "generic" comparison engine that works on every EMF models you can find. The disadvantage of a generic engine, though, is that it cannot know of specific needs. UML models, for example, have a number of features that EMF Compare cannot properly handle in a generic manner.<br /><br />We now provide along with EMF Compare 1.2.0 an UML-specific comparison engine to take care of that metamodel. For example, here is what the generic engine detects when applying a stereotype to a Class :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4XQvC0TIZcskqmekpcDbgaIE7QTOVHbRoTu6ORRByO4tyI3X6ELnvxRT06xWCcbHtbv18eT-FOd1LSukoDCZEKEg_jGSwxTxEwmUTdLFN6hHG9zLYRI0mIV90aK26lrIKHCM8xS8dOAPN/s1600/stereotypeApplication-generic.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 208px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4XQvC0TIZcskqmekpcDbgaIE7QTOVHbRoTu6ORRByO4tyI3X6ELnvxRT06xWCcbHtbv18eT-FOd1LSukoDCZEKEg_jGSwxTxEwmUTdLFN6hHG9zLYRI0mIV90aK26lrIKHCM8xS8dOAPN/s320/stereotypeApplication-generic.png" alt="" id="BLOGGER_PHOTO_ID_5618740144323113010" border="0" /></a><br />And here is what can will be detected and displayed by the UML specific engine :<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1YT9Qo5hLlr5GZhjHwWh18NXAUGwvAjJ-2eI_C1O-Gg0qTWQU7JxU1tcfWt-UOqT-ntE1VO443xeNDewkmPe5feK6rBhwz5ADWfIxLJLMHCmXl4iqIbWcYuxfwbifiXoQQ8muj0alj3Fa/s1600/stereotypeApplication-uml2.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 207px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1YT9Qo5hLlr5GZhjHwWh18NXAUGwvAjJ-2eI_C1O-Gg0qTWQU7JxU1tcfWt-UOqT-ntE1VO443xeNDewkmPe5feK6rBhwz5ADWfIxLJLMHCmXl4iqIbWcYuxfwbifiXoQQ8muj0alj3Fa/s320/stereotypeApplication-uml2.png" alt="" id="BLOGGER_PHOTO_ID_5618740150217587698" border="0" /></a><br />This UML comparison engine is still in its early stages and will be improved in the months to come, but it is still provided for early adopters. Further technical information about this extension are described on <a href="http://wiki.eclipse.org/EMF_Compare/UML_Compare#UML_Extensions">the Eclipse wiki</a>.<br /><br />Most of these features have been implemented as part of the <a href="http://wiki.eclipse.org/ModelingPlatform">Modeling Platform working group</a>.<br /></newvalue></oldvalue></classname></attributetype></attributename>Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-60108489916012311182011-06-07T08:11:00.000-07:002011-06-07T08:29:35.376-07:00Acceleo query cacheSome of our users have been bit by the fact that <a href="http://www.eclipse.org/acceleo/">Acceleo</a> caches the result of Query invocations, returning the very same result each time a given query is called. These users often came with the same two questions : "why?" and "Can this cache be disabled in my case?".<br /><br />The answer to the first has always been and will remain the same : Acceleo is an implementation of the OMG's <a href="http://www.omg.org/spec/MOFM2T/1.0/">MOFM2T 1.0 specification</a>, and this specification tells us that<br /><ul><li>A <span style="font-style: italic;">query</span> is required to produce the same result each time it is invoked with the same arguments.</li></ul>That is the reason we decided to cache the result : in order to return that same result each time the query is called, without re-evaluating it.<br /><br />The answer to the second, however, changes with the 3.1.0 release of Acceleo : even though we strive to be as close as possible to the specification, there are times where this caching of the query return values is not desirable : it can be really costly memory-wise, it could be a call to a Java method that has random results, it could be a query which return value changes according to variable states that are not passed as parameters... That was possible through programmatic calls in 3.0.2, but we've decided to make that preference available through the UI in 3.1.0 :<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihz1Y6qzW00JW3ZXGDqY2YwoUsw5w3qZ7oQIgk9hvUB02PWKP_v_Ho6LW2WeGXehYriNRiStozYF_gSuMBOh-h9sp1g3AicWqVjZBwX8dyyT3p9jAPSMTa0_1EodxN1vByyjo983G7obS8/s1600/Acceleo_preferences.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 279px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihz1Y6qzW00JW3ZXGDqY2YwoUsw5w3qZ7oQIgk9hvUB02PWKP_v_Ho6LW2WeGXehYriNRiStozYF_gSuMBOh-h9sp1g3AicWqVjZBwX8dyyT3p9jAPSMTa0_1EodxN1vByyjo983G7obS8/s320/Acceleo_preferences.png" alt="" id="BLOGGER_PHOTO_ID_5615500195663429586" border="0" /></a><br />The next step is to have the specification evolve in order to be able to disable the query cache "per-query" instead of globally but... that's another story :).<br /><span style="display: block;" id="formatbar_Buttons"><span onmouseover="ButtonHoverOn(this);" onmouseout="ButtonHoverOff(this);" onmouseup="" onmousedown="CheckFormatting(event);FormatbarButton('richeditorframe', this, 8);ButtonMouseDown(this);" class=" down" style="display: block;" id="formatbar_CreateLink" title="Link"></span></span>Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com6tag:blogger.com,1999:blog-3658502096185788177.post-78398707339673132512011-04-22T05:09:00.000-07:002011-04-22T07:05:34.796-07:00Acceleo syntax coloringI announced in my <a href="http://eclipsemde.blogspot.com/2011/03/acceleo-over-rainbow.html">latest message</a> that the syntax highlighting colors of Acceleo would soon be configurable. Well, the preference page has now made its apparition and will definitely be available in the 3.1.0M7 build of Acceleo.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhF84jSjLjc2rTVh9OBdzbegAR3B1k0REsXTG-6J1nlHngoKmRlVqlXZ2IbvcYdsLE47Tx4D0gdGYQKyTXdnnBcJJvNH9un-k3zzsgp5ObKtnJGdP91pS4AT3A4qk1_K6-R6VNUnJGJQGny/s1600/preferencePage.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 316px; height: 320px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhF84jSjLjc2rTVh9OBdzbegAR3B1k0REsXTG-6J1nlHngoKmRlVqlXZ2IbvcYdsLE47Tx4D0gdGYQKyTXdnnBcJJvNH9un-k3zzsgp5ObKtnJGdP91pS4AT3A4qk1_K6-R6VNUnJGJQGny/s320/preferencePage.png" alt="" id="BLOGGER_PHOTO_ID_5598408164911701730" border="0" /></a><br />If anyone would like to contribute, we're still missing import/export capabilities to make these color themes easier to share between Eclipses and colleagues; we'd gladly accept such contributions :).Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-6291346857664779862011-03-28T08:13:00.000-07:002011-04-04T00:53:25.457-07:00Acceleo over the rainbowWe've often had complaints about the default choice of colors we made for the Acceleo template editor :<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2nVq4NGRQpPo_SuZ9s-ml6R996txfMWc5NybQ_tNX46Vr2qAmftzp6Iab6L_ims6BDPKz5aE0nn305YF0NuwQNDs-kJraZPBWMCxpgB1xB-u4E5gGowsY5P9wkhoXC1OYxplm9ukwyL4a/s1600/default.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2nVq4NGRQpPo_SuZ9s-ml6R996txfMWc5NybQ_tNX46Vr2qAmftzp6Iab6L_ims6BDPKz5aE0nn305YF0NuwQNDs-kJraZPBWMCxpgB1xB-u4E5gGowsY5P9wkhoXC1OYxplm9ukwyL4a/s320/default.png" alt="" id="BLOGGER_PHOTO_ID_5589501809985387106" border="0" /></a><br />For example, people who like high contrast themes, or who'd rather develop with a white/green font on a black/gray background complained that this colors were unusable when using such backgrounds. And since we inherit the background color from the default "text editor background" color, this could give awful results :<br /><br /><default_black_bg.png><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv92VdHVGlXQuAPBBNgJ9b7THOWHG30S2TIomZeW7aVizbyMuGM-_RXiL6vmt4Wpyyltp1oCSnwEx1OfQoQFpNkGjmxXLaGD6H3_8eO6j-QEIb6KZP_OVom328EdWiWrGi_5ZY1y9qAfKR/s1600/default_black_bg.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv92VdHVGlXQuAPBBNgJ9b7THOWHG30S2TIomZeW7aVizbyMuGM-_RXiL6vmt4Wpyyltp1oCSnwEx1OfQoQFpNkGjmxXLaGD6H3_8eO6j-QEIb6KZP_OVom328EdWiWrGi_5ZY1y9qAfKR/s320/default_black_bg.png" alt="" id="BLOGGER_PHOTO_ID_5589501824340094130" border="0" /></a><br />There were also those that simply didn't like to have "red" text in their code, since this color usually reflect an error of some kind :). As hinted from <a href="http://sbegaudeau.tumblr.com/post/4254713128/a-new-direction-for-acceleo">Stéphane's recent post</a>, we've decided to make these colors customizable in Acceleo 3.1. And even though his "rainbow" theme was a little extreme (just in time for april's fool), it did show a number of the areas that now get individually customizable.<br /><br />We hope to include import/export facilities for these color schemes, and the rainbow scheme will most likely be included along with the default :).<br /><br />I know my editor will more or less look like this (but I kind of find blue-ish themes easy on the eye) :<br /><br /><ocean.png><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimZOg5Ayx_LntL_S83MB2xmprC61HcG66lP768S8azhqbrTsVOq9R1QBRPr5SGtZ2ehjM5ZcVQci35Gonvt2kW8D4tYe028S5EQYZ4sIf90TQTbRo3_LZhrDwbbVdbf1WGYc4QGmEJ3A7b/s1600/ocean.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimZOg5Ayx_LntL_S83MB2xmprC61HcG66lP768S8azhqbrTsVOq9R1QBRPr5SGtZ2ehjM5ZcVQci35Gonvt2kW8D4tYe028S5EQYZ4sIf90TQTbRo3_LZhrDwbbVdbf1WGYc4QGmEJ3A7b/s320/ocean.png" alt="" id="BLOGGER_PHOTO_ID_5589501816151114994" border="0" /></a><br />How will be yours? Look forward for the 3.1M7 build for these options :).<br /></ocean.png></default_black_bg.png>Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com9tag:blogger.com,1999:blog-3658502096185788177.post-83323209687830910902010-12-21T01:50:00.000-08:002010-12-21T05:01:47.989-08:00Acceleo vs Acceleo vs XpandWe've recently had a good number of people asking for comparisons between <a href="http://acceleo.org/pages/home/en">Acceleo 2</a> and its new major version <a href="http://www.eclipse.org/acceleo/">Acceleo 3</a>. Some people also wondered how Acceleo ranked compared to the other trendy code generation tool, <a href="http://www.eclipse.org/modeling/m2t/?project=xpand">Xpand</a>. The three have the same goal : generating text from models, let's take a closer look at their respective performances.<br /><br />With the migration capabilities we have between Acceleo 2 and Acceleo 3, comparing those two has proven rather easy; comparing them with Xpand has been a little more trouble for me as I am not familiar to this tool. I still attained a result I believe to be interesting.<br /><br />I didn't make in-depth comparisons between the tooling of each of these three tools, focusing on the generation performance only. GUI comparison may come later, when I have the courage :).<br /><br />What I did compare was the generation performance for a given set of generation templates that I ported to all three of the technologies. The result is that all three tools (Acceleo 2, Acceleo 3 and Xpand 1.0.1) generate the very same java code, whitespaces excepted.<br /><br />Each of the times outlined below is the average of three runs on the same machine :<br />- Intel Core 2 Duo 64 bits<br />- Dual core, 2GHz by core<br />- 4 Go RAM<br />- Windows seven 64bits<br /><br />The version of Java installed on this machine was Java SE 1.5.0_22 64bits.<br /><br />The Eclipse platform version was Eclipse Helios 3.6.1 (64 bits still). Each tool was installed within its own Eclipse with only its dependencies and the dependencies of the tests.<br /><br />I've run two distinct use cases for this benchmarking :<br />- "Small" corresponding to the generation with a small model as input. I used UML.genmodel for this, which in turn links to UML.ecore, Ecore.ecore and Ecore.genmodel. When counting the content of the two main models used by this transformation, UML.genmodel and UML.ecore (just a basic count of eAllContents), I get a total of 14 420 elements.<br />- "Medium" corresponding to the generation of medium models as input. For this, I generated a metamodel with a fixed number of classes, enumerations and datatypes, then the corresponding genmodel. Like above, a basic count of the model content yields a total of 50 944 elements.<br /><br />As far as generated files go, the "small" use case generates 217 java classes for a total of 200 921 lines of code. The "medium" use case generates 1 206 java files for a total of 838 273 lines of code.<br /><br />All measures have been taken "at worst", launching the generation in a new Eclipse runtime (thus, nothing in cache, no plugin loaded yet). The times given here are in seconds, and they correspond to the average of three runs. One measure comprises the time to load the model, the time to evaluate the generation and the time to serialize the result.<br /><br />Without further ado, here are the figures :<br /><br /><table frame="VOID" rules="NONE" border="0" cellspacing="0" cols="4"> <colgroup><col width="86"><col width="86"><col width="86"><col width="86"></colgroup> <tbody> <tr> <td align="LEFT" height="17" width="86"><span style="font-family:Times New Roman;"><br /></span></td> <td style="border: 1px solid rgb(0, 0, 0);" align="CENTER" width="86"><b><span style="font-family:Times New Roman;">Acceleo 2</span></b></td> <td style="border: 1px solid rgb(0, 0, 0);" align="CENTER" width="86"><b><span style="font-family:Times New Roman;">Acceleo 3</span></b></td> <td style="border: 1px solid rgb(0, 0, 0);" align="CENTER" valign="MIDDLE" width="86"><b><span style="font-family:Times New Roman;">Xpand</span></b></td> </tr> <tr> <td style="border: 1px solid rgb(0, 0, 0);" align="LEFT" height="17"><span style="font-family:Times New Roman;">Small</span></td> <td style="border-bottom: 1px solid rgb(0, 0, 0); border-right: 1px solid rgb(0, 0, 0);" align="CENTER"><span style="font-family:Times New Roman;">50 s<br /></span></td> <td style="border-bottom: 1px solid rgb(0, 0, 0); border-left: 1px solid rgb(0, 0, 0); border-right: 1px solid rgb(0, 0, 0);" align="CENTER"><span style="font-family:Times New Roman;">10 s<br /></span></td> <td style="border-bottom: 1px solid rgb(0, 0, 0); border-left: 1px solid rgb(0, 0, 0); border-right: 1px solid rgb(0, 0, 0);" align="CENTER"><span style="font-family:Times New Roman;">25 s<br /></span></td> </tr> <tr> <td style="border: 1px solid rgb(0, 0, 0);" align="LEFT" height="18"><span style="font-family:Times New Roman;">Medium</span></td> <td style="border-top: 1px solid rgb(0, 0, 0); border-bottom: 1px solid rgb(0, 0, 0); border-right: 1px solid rgb(0, 0, 0);" align="CENTER"><span style="font-family:Times New Roman;">215 s<br /></span></td> <td style="border: 1px solid rgb(0, 0, 0);" align="CENTER"><span style="font-family:Times New Roman;">25 s<br /></span></td> <td style="border: 1px solid rgb(0, 0, 0);" align="CENTER"><span style="font-family:Times New Roman;">212 s<br /></span></td> </tr> </tbody> </table><br />Being an Acceleo developper myself, I can only be pleased by these results ... Even though the test might be seend as biased as a result :p. All of the files needed to replay these can be downloaded from <a href="http://www.eclipse.org/modeling/m2t/acceleo/ecore2unittests.bench.zip">here</a>. On that matter, as I am not familiar with Xpand, please don't hesitate to optimize the templates if at all possible (though the Acceleo 3 templates themselves don't use the latest evolutions of Acceleo 3.1).Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-29147758980512753372010-10-12T02:03:00.000-07:002010-10-12T02:33:33.318-07:00Open World Forum Demo cup award 2010The <a href="http://www.openworldforum.org/">Open World Forum</a> took place in Paris on September 30 and October 1. This was a great opportunity to discover open source tools and technologies, as well as getting to know great people of this field. The 2010 edition has attracted over 1500 participants from 40 countries!<br /><br />Obeo was present and demonstrated the use of Acceleo 3 to generate android applications, this demo earned us the <a href="http://www.openworldforum.org/connect/awards">Demo Cup 2010 award</a>! This award is given to recognize the most innovative and game-changer open source solution in its marketplace.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.eclipse.org/acceleo/images/openInnovationAward.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 155px; height: 101px;" src="http://www.eclipse.org/acceleo/images/openInnovationAward.png" alt="" border="0" /></a>Acceleo, selected from 13 top nominees, received one of five prestigious trophies at the closing ceremony of the Open World Forum, awarded by a jury consisting of leading international experts in the open source world. <a href="http://www.openworldforum.org/connect/awards"></a><p> </p><p> After the <a href="http://www.eclipse.org/org/press-release/20090323_AwardsWinners.php">Eclipse Community Award in 2009</a>, this prize recognizes the constant efforts of the Acceleo team & community to provide a powerful tool of the highest quality. </p>Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-72991277398307274932010-08-16T01:10:00.000-07:002010-08-16T01:51:19.589-07:00User interface improvements in Acceleo 3.1Acceleo 3.1.0 is due June, 22 2011 along with Eclipse Indigo ... seems far, but not as far away as we sometimes hope for with all the features we'd like to add in our products.<br /><br />Because of this, we've already started implementing some of the (many) improvements we'd like to make in the Acceleo editor : support for template, query and module documentation, support for more markers to display feedback to the user (information, warning, "overriding" link...), support for tasks in the template (TODO, FIXME, ...), improvement of the oultine, feedback on the non-printable characters that will be generated ...<br /><br />Stephane Begaudeau is reponsible for most of these first additions, you can find a list, detailed explanations and screenshots in <a href="http://sbegaudeau.tumblr.com/post/961722949/user-interface-improvements-in-acceleo-3-1">this great post</a>.<br /><br />Most of these improvements have already found their way in the source code and will be available in the 3.1M1 release of Acceleo tomorrow, care to test? Or are there features <u>you</u> would like to see in the Acceleo module editor? Don't hesitate to take part in the discussions, raise bugs or provide feedback on either <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2T&component=Acceleo">bugzilla</a> or <a href="http://www.eclipse.org/forums/index.php?t=thread&frm_id=24&S=18c8db06f221c1e188c27f145258820b">forum</a> :).Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-56973979486717685852010-06-30T01:25:00.000-07:002010-06-30T04:40:38.609-07:00Using code generation under ClearCaseThose of you that know ClearCase also know that it requires the user to check out the file he wishes to edit before any editing can be done; kind of trying to edit a read-only file : you need to remove the read-only flag before anything else. Of course, this doesn't fit well with code generation tools such as Acceleo since the aim of such tools is to edit (or create) a number of files at once.<br /><br />Until now that is :). Acceleo can now be used in conjunction with ClearCase or other pessimist-locking Version Control Systems (VCS). How does it work?<br /><br />You might have noticed the "<span style="font-family:courier new;">getGenerationStrategy()</span>" method of the Java class we generate for your main mtl files; this is the method that matters for us. You simply need to change it from its default "<span style="font-family:courier new;">return super.getGenerationStrategy()</span>" to "<span style="font-family:courier new;">return new WorkspaceAwareStrategy()</span>" and you're done! Acceleo will now prompt the users of your generators to check out the files before attempting to modify them.<br /><br />Two things to note :<br /><ul><li>You must change the javadoc of "<span style="font-family:courier new;">getGenerationStrategy()</span>" so that it doesn't contain "<span style="font-family:courier new;">@generated</span>" anymore : delete this tag, change it to "<span style="font-family:courier new;">@not-generated</span>", change it to "<span style="font-family:courier new;">@generated NOT</span>"... just don't leave this tag as-is or the Acceleo builder will override your change.</li><li>You cannot use this strategy in standalone mode, its goal is to integrate with the Eclipse workspace and its team providers.</li></ul>The use case with ClearCase or pessimist locking VCSs is obvious, but you might realize that there is more to it that just these. You could be trying to regenerate a file that you set as read only, a file under SVN that requires a lock...<br /><br />For example, with SVN you can set the property "svn:needs-lock" on a file to prevent any edition without prior locking. If you attempt to regenerate a file with such a property set with Acceleo, here is what you will get :<br /><br />"<span style="font-family:courier new;">java.io.FileNotFoundException: [...]</span><span style="font-family:courier new;">\Library.java (Access denied)</span>"<br /><br />Pretty mean, huh? If you make use of the <span style="font-family:courier new;">WorskpaceAwareStrategy</span> though, you will get this instead :<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVv5p_BysThl7bFpaJ0tSJ07LbxusLpJkhmFwSxwrrTQmQrLzFkL44OJtu4-2OKJiwEp1P-IRL3sk-F2sYySABDzsFvTNo7Utv-ISsBS7-DfIPfRMOYlSvHl-Bsm2IBJ5H6C_lI0wiV4Re/s1600/SVN_Lock.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 286px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVv5p_BysThl7bFpaJ0tSJ07LbxusLpJkhmFwSxwrrTQmQrLzFkL44OJtu4-2OKJiwEp1P-IRL3sk-F2sYySABDzsFvTNo7Utv-ISsBS7-DfIPfRMOYlSvHl-Bsm2IBJ5H6C_lI0wiV4Re/s320/SVN_Lock.png" alt="" id="BLOGGER_PHOTO_ID_5488528289793056642" border="0" /></a>All you have to do is to tick off the files for which you wish to take the lock. Files you do not check will not be locked for edition.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-9839490951495519362010-06-11T02:08:00.000-07:002010-06-11T02:57:52.346-07:00Package with URI '*' not foundI believe most of the users of EMF (developers or adopters alike) have seen this message at least once; and most probably wondered what was going on :).<br /><br />This error message indicates that the package which NsURI is '*' hasn't been registered in the Package registry. Most of the time, that means you either a) launched your program standalone and didn't register the package correctly or b) you haven't installed the plug-in that provides that metamodel.<br /><br />With <a href="http://www.eclipse.org/acceleo/">Acceleo</a>, encountering this exception is even more likely than normal, as the launch configuration for our generations allow for both <span style="font-style: italic;">standalone</span> or <span style="font-style: italic;">plug-in</span> generations. Selecting <span style="font-style: italic;">standalone</span> without registering the needed package will inevitably lead to this error.<br /><br />Solving it is easy : it is a matter of registering the needed packages (and, optionally, resource factories). How is it done? Here is the most classic example with UML :<br /><br /><span style="font-size:85%;"><span style="font-family:courier new;">Package with uri 'http://www.eclipse.org/uml2/2.1.0/UML' not found.</span></span><br /><br />What do I need to do for my UML model to be loadable :<br /><br /><span style="font-size:85%;"><span style="font-family:courier new;">EPackage.Registry.INSTANCE.put(UMLPackage.eNS_URI, UMLPackage.eINSTANCE);<br /><span style="font-family:courier new;">Resource.Factory.Registry.INSTANCE</span></span><span style="font-family:courier new;">.getExtensionToFactoryMap().put(UMLResource.FILE_EXTENSION, UMLResource.Factory.INSTANCE);</span></span><span style="font-size:85%;"><span style="font-family:courier new;"></span><br /></span><br />The same goes for every metamodel you might need, simply change <span style="font-size:85%;"><span style="font-family:courier new;">UMLPackage</span></span> by <span style="font-size:85%;"><span style="font-family:courier new;">XxxPackage </span></span>according to your metamodel. The Resource Factory is mandatory for UML, but your metamodel might not need one; simply ignore this line if you don't have a custom factory.<br /><br />You need these two lines to be <u>before</u> the point where your model is loaded. For Acceleo, this is done in the generated Java launcher : simply change the implementation of the <span style="font-size:85%;"><span style="font-family: courier new;">registerPackages</span></span> and <span style="font-size:85%;"><span style="font-family: courier new;">registerResourceFactories</span></span> method to add these needed lines.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com3tag:blogger.com,1999:blog-3658502096185788177.post-88036959571984779472010-06-08T07:21:00.000-07:002010-06-08T07:56:12.211-07:00New Acceleo homepageThe <a href="http://www.eclipse.org/acceleo/">Acceleo homepage</a> now makes use of the template <a href="http://www.heikobehrens.net/2010/01/07/recent-updates-of-the-xtext-website/">provided by Heiko Behrens</a>.<br /><br />You've seen it with MoDisco, you've seen it with Xtext, it's now our turn to change skin :).<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNobUYwfaM4PUalSZsHnWHg5kiBl4MVhyphenhyphen0gtqycrFypIwIQDZPdCJBQFujbNXN-U1JWPzSr6Y9Qrju5r6YqRWs60Y3Di1obEhISDeYyHQC6ATxSMR4truH1V5mG2RuHHhesBqpZv82Jhl_/s1600/Acceleo_website.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 277px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNobUYwfaM4PUalSZsHnWHg5kiBl4MVhyphenhyphen0gtqycrFypIwIQDZPdCJBQFujbNXN-U1JWPzSr6Y9Qrju5r6YqRWs60Y3Di1obEhISDeYyHQC6ATxSMR4truH1V5mG2RuHHhesBqpZv82Jhl_/s320/Acceleo_website.png" alt="" id="BLOGGER_PHOTO_ID_5480416001364891010" border="0" /></a>This also makes use of the changes brought to the CSS by <a href="http://fmadiot.blogspot.com/2010/06/new-modisco-homepage.html">Fred Madiot</a>.<br /><br />Thanks to both of them !Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-60743046757871982772010-06-01T07:15:00.001-07:002010-06-01T07:15:48.826-07:00What's new in Acceleo 3.0?<a href="http://wiki.eclipse.org/Acceleo">Acceleo</a> 3.0 is on its way out. It is <a href="http://www.eclipse.org/modeling/m2t/downloads/?project=acceleo">currently accessible in its third Release Candidate (RC3)</a> version. The complete list of improvements and bug fixes that have been implemented in this version since the last stable release (version 0.8.1, see my previous post for <a href="http://eclipsemde.blogspot.com/2010/03/acceleo-graduation-version-jumping-and.html">explanation on this branch's version numbering</a>) is humongous; following is the list of the most important ones. I may be succinct on the description of some of these, but you can get a full explanation of all of them in the Acceleo documentation, namely the <span style="font-weight: bold;">User Guide</span>. Be warned though, this will be a huge post :).<br /><br /><div style="text-align: center;"><span style="font-weight: bold;">Compatibility and upgrading</span><br /></div><ul><li>Acceleo 3.0 is compatible with the three latest releases of Eclipse; Eclipse 3.4 (Ganymede), Eclipse 3.5 (Galileo) and Eclipse 3.6 (Helios). However, there are some limitations to this compatibility we maintain due to the changes that were implemented in OCL since then. For one, Acceleo modules that compile in Helios may or may not compile in Galileo and Ganymede (this will depend on the OCL features you make use of). However, Acceleo modules that compile in a given version will always compile in the subsequent Eclipse releases. Likewise, a module that has been compiled in Helios may be launched in Ganymede regardless of whether it would compile or not in that version, as our runtime shouldn't suffer from OCL breakages and improvements. All information about the compatibility will be maintained on the <a href="http://wiki.eclipse.org/Acceleo#Compatibility">wiki</a>.<br /></li><li>We provide migration facilities for those of you that own Acceleo 2 templates. Specifically, we allow for the automatic migration of Acceleo 2 generation projects to Acceleo 3 projects. The automatic migration takes care of everything that could possibly be automated, leaving for you to fix no more than the Acceleo 2 features that don't have an identified mapping to Acceleo 3, or those few features that require a human hand to convert intelligently. The team is at your disposal for help if there still remains things you don't know how to convert to Acceleo 3 on the usual communication channels : the M2T newsgroup, mails, comments on this blog...</li></ul><div style="text-align: center;"><span style="font-weight: bold;">Tooling improvements</span><br /></div>New views have been introduced to help you on several aspects of the generation cycles : module definition, launching, debugging. I'll detail each of these views one after the other.<br /><ul><li>First of all, the <span style="font-style: italic;">Result</span> view allows you to get feedback on the traceability information we could retrieve during the evaluation of your modules. As long as this view has been opened, Acceleo will record every bit of information it can to synchronize your generated text with the generation module and source model. Ever wondered why such or such portion of text has been generated one way or another? What part of your generation module has generated the name of such or such method? From which element of your model has been generated such or such import? This is the view you can use to retrieve these pieces of information.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtbKsnOu_ZBXMZv9KMYYpko6KtpT3yhyJL_sXBMPaQDzmkD6jtzGIRkBpH2uC2m7Dfi_B8Fd_fDqV4D_UXaOeRRJAsfR4Z6xHZd6lcZu8Qc1j_bDJVnutljY0cLj6oOdfSImjqhriry_n-/s1600/acceleo_result_view1.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 138px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtbKsnOu_ZBXMZv9KMYYpko6KtpT3yhyJL_sXBMPaQDzmkD6jtzGIRkBpH2uC2m7Dfi_B8Fd_fDqV4D_UXaOeRRJAsfR4Z6xHZd6lcZu8Qc1j_bDJVnutljY0cLj6oOdfSImjqhriry_n-/s320/acceleo_result_view1.png" alt="" id="BLOGGER_PHOTO_ID_5475947452178727362" border="0" /></a></li><li>Next comes the <span style="font-style: italic;">Overrides</span> view, which can be used to easily create templates or modules overriding other that are present in your instance of Eclipse. It will display every single module located either in your installed plug-ins or your workspace. All of these can be browsed down to the template level and a check box allows you to select those you wish to override. Once selected, you simply have to use the content assistant in the Acceleo Editor (<span style="font-style: italic;">CTRL+SPACE</span> by default) and validate <span style="font-style: italic;">selected ov</span><span style="font-style: italic;">errides</span> for all of the overriding templates to be added to your module.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX0JQX7_dA1mEAm-rkZ7Zpc2HfP3oB62P7nRbavDbqKRmijOkHDwohpQHlHSZZXDf6Aq7EI_SRGg3FmTJeurmcxPjIRj8cy7YH82P68bQHaOia4sQYx2z28hC_KUyRlDGFGlPxCHAx8Bzv/s1600/acceleo_overrides_view2.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 105px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX0JQX7_dA1mEAm-rkZ7Zpc2HfP3oB62P7nRbavDbqKRmijOkHDwohpQHlHSZZXDf6Aq7EI_SRGg3FmTJeurmcxPjIRj8cy7YH82P68bQHaOia4sQYx2z28hC_KUyRlDGFGlPxCHAx8Bzv/s320/acceleo_overrides_view2.png" alt="" id="BLOGGER_PHOTO_ID_5475948346721411682" border="0" /></a></li><li>Last but not least, the <span style="font-style: italic;">Generation Patterns</span> view has been introduced to help you implement behavior for an interface/class and all (or a subset of) its subtypes. For example, let's say you wish to implement a template named <span style="font-family:courier new;">javaName</span> which will generate the name of any classifier. This template will need some default behavior for interfaces and specific behavior for some classifiers. Open the Generation Patterns view, tick <span style="font-style: italic;">[template] for all selected types</span> in its top part, and all of the types you wish to generate a template for in its bottom part. Once done, the content assist in the Acceleo editor will give you the choice <span style="font-style: italic;">[template] for all selected types</span> which you just have to choose in order to generate all of the templates you asked for. Now that you no longer risk forgetting one or more subtypes, it is left to your discretion to implement the behavior for each of them.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6rCTYqJ1Fh6aqAOexWqrv80SJ7W5RCRFerwN3KR8Rv-bQ03K0BOn_CEiK7gL5LXFoCVKwIWshBNrAhwvY_vJUZlZMoVhtKQkZK_Pftk8ewCab59CNCIfb4mlqWxzyNZbxnc01soUe0kgQ/s1600/acceleo_generation_patterns1.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 190px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6rCTYqJ1Fh6aqAOexWqrv80SJ7W5RCRFerwN3KR8Rv-bQ03K0BOn_CEiK7gL5LXFoCVKwIWshBNrAhwvY_vJUZlZMoVhtKQkZK_Pftk8ewCab59CNCIfb4mlqWxzyNZbxnc01soUe0kgQ/s320/acceleo_generation_patterns1.png" alt="" id="BLOGGER_PHOTO_ID_5475960097059976578" border="0" /></a></li><li>Acceleo now provides a built-in profiler that can be used to keep track of evaluations and identify (and, hopefully, fix) bottlenecks in your generation process. The profiler is accessible through a right click on the module which execution you need to profile and the menu item <span style="font-style: italic;">Profile As => Acceleo Application</span>.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHFzndOpMrCTL5gN4rDUI5nPT9gXxpMmMd_bo6oiTaiY9tvSNwxP8zlYs11FNtmJM1hlJqi5nvb_LpUsTfudgIH_zaVdqhVI9sjFQmRUxz3stdPfcfrQexPfzPUsKSWxNkTgu7_rzeKBOy/s1600/acceleo_profiling_file2.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 166px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHFzndOpMrCTL5gN4rDUI5nPT9gXxpMmMd_bo6oiTaiY9tvSNwxP8zlYs11FNtmJM1hlJqi5nvb_LpUsTfudgIH_zaVdqhVI9sjFQmRUxz3stdPfcfrQexPfzPUsKSWxNkTgu7_rzeKBOy/s320/acceleo_profiling_file2.png" alt="" id="BLOGGER_PHOTO_ID_5475970073580587026" border="0" /></a></li><li>The Acceleo debugger now provides you with the list of available variables at a given point in the evaluation process, along with the values of these variables for a given stack frame. Moreover, the displayed stack frames now represent Acceleo module element corresponding to your current expression stack. As for the previous release, debugging templates only requires you to set breakpoints in the Acceleo modules as you would usually with Eclipse : open an editor, double click in the left margin on the line you wish the breakpoint to be set, and launch the generation through the menu <span style="font-style: italic;">Debug As => Launch Acceleo Application</span>.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6L63AOgxg1RQcjpYdDAGq8xkmyymvQ_qkdAcEtP1DKwvhibhFg5V-gIV5wxZzqZ6uyWUnA0SodI45CbHDEZ6i2fASBL5uMKKvlXww5CBdgpzCNb0r7J8UgvBWUGt3mqjkf-uHa72-mKbX/s1600/acceleo_debug.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 195px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6L63AOgxg1RQcjpYdDAGq8xkmyymvQ_qkdAcEtP1DKwvhibhFg5V-gIV5wxZzqZ6uyWUnA0SodI45CbHDEZ6i2fASBL5uMKKvlXww5CBdgpzCNb0r7J8UgvBWUGt3mqjkf-uHa72-mKbX/s320/acceleo_debug.png" alt="" id="BLOGGER_PHOTO_ID_5476234478481154274" border="0" /></a></li><li>Whenever possible, the warnings and errors Acceleo logs when an evaluation fails now sport the expression stack (with the lines they're at in the module files) instead of a stack trace corresponding to the Java code that was being executed at the time. This will allow for way easier debugging that ever before.</li></ul><br /><div style="text-align: center;"><span style="font-weight: bold;">Editor Improvements</span><br /></div>Apart from the performance improvements and minor bug fixes, the Acceleo module editor now provides refactoring actions and quick fixes.<br /><ul><li>First of all, you can now use the “usual” shortcut <span style="font-style: italic;">ALT+SHIFT+R</span> to rename either modules, templates, queries, variables, ... in a coherent manner. This very same action can be accessed from right-clicking and selecting <span style="font-style: italic;">Refactor => Rename</span>. The interface will allow you to preview the changes before validating them.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2lEF2-pF9haWdrybvPxczOqh2mp0hg385J5UgQX10bb3OcOIa_tuaN9HIrkFYjsAc_RTccWMTAudOUMUVGA2W06S0VEQtBiDEmq_wQZRSrLQOGmlcz_AIxWbiL8ehtmDXAROG-TGl8496/s1600/acceleo_rename_preview.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 215px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2lEF2-pF9haWdrybvPxczOqh2mp0hg385J5UgQX10bb3OcOIa_tuaN9HIrkFYjsAc_RTccWMTAudOUMUVGA2W06S0VEQtBiDEmq_wQZRSrLQOGmlcz_AIxWbiL8ehtmDXAROG-TGl8496/s320/acceleo_rename_preview.png" alt="" id="BLOGGER_PHOTO_ID_5476236048589161586" border="0" /></a></li><li>Portions of the module elements can be extracted as new templates through right-clicking and selecting <span style="font-style: italic;">Refactor => Extract Template</span> (or simply using the shortcut <span style="font-style: italic;">ALT+SHIFT+T</span>). Do note, however, that the selected text needs to be consistent. You cannot randomly select text that spans blocks of code and expect an adequate result.<br /></li><li>The module editor now highlights all occurrences of the selected element when you click on it. For exemple if you place the cursor on the name of a template, all invocations of this template will be highlighted and markers will appear on the right ruler of the editor to indicate them.</li><li>Acceleo now provide quick fixes for some of the syntax errors detected in the editor, notably the possibility to create template or queries of a corresponding name.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcHlAZvTh-cGAuC6BpIvFX9hYhkkqP1lcYN2TdlRCFRVKsKPq2PE4toUPrHVLwJt8euDCr_G9lF6KHDQ7AS-_JlxTCY1PgR8WACM6eD95I5eezHeUsMWPlWOmsI765wzNa4tLgBjoUz9dQ/s1600/acceleo_quick_fixes.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 152px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcHlAZvTh-cGAuC6BpIvFX9hYhkkqP1lcYN2TdlRCFRVKsKPq2PE4toUPrHVLwJt8euDCr_G9lF6KHDQ7AS-_JlxTCY1PgR8WACM6eD95I5eezHeUsMWPlWOmsI765wzNa4tLgBjoUz9dQ/s320/acceleo_quick_fixes.png" alt="" id="BLOGGER_PHOTO_ID_5476239096867878146" border="0" /></a></li><li>It is recommended to use a bottom-up approach when developing generators ; Acceleo now eases this process by allowing you to initialize the content of a generation module with an example, and offering specific actions to transform these examples (static text) in dynamic OCL expressions. For example, changing all occurrences of <span style="font-family:courier new;">MyClass</span><span style="font-style: italic;"> </span>to <span style="font-family:courier new;">[c.name.toUpperFirst()/]</span> in a single click.</li></ul><br /><div style="text-align: center;"><span style="font-weight: bold;">Improvements and simplifications of the language</span><br /></div><ul><li>The MTL specification defines a <span style="font-style: italic;">standard library</span> that offers a set of utility operations; in addition, Acceleo provides a <span style="font-style: italic;">non standard library</span> to provide operations that greatly simplify the language and allow you to write more concise expressions, but are not part of the specification. This library has seen many additions since the 0.8 version, with things like <span style="font-family:courier new;">Collections::sep(String)</span> to insert a separator in-between every element contained by a collection, <span style="font-family:courier new;">String::matches(String)</span> to check whether a given String matches a regular expression, <span style="font-family:courier new;">Collection::filter(Type)</span> that can be used to filter out of a collection all elements that are not instances of a given type, <span style="font-family:courier new;">Collection::reverse()</span> to reverse the content of a given Collection... Take a look at the Acceleo documentation for a full reference of both standard and non standard library, along with the reference of the OCL standard library.</li><li>Acceleo allows you to alter the build mode, either Strict or Lax MTL compliance. Strict compliance meaning you'll get a warning for each use of a “non standard” operation.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPaSyg41u6jThsstQA5XeXiGp4l_ujrcNFnSJDo7k0rZh9R9V4FmNVIw-Yw_eP6SjxLwO2BM9y2gVM_e-YGGOBbVVCT5XfTu7stUjTXPzJIwPz7dkrFXYrRn-n42uYboX-6REwwApiARu-/s1600/acceleo_compiler_compliance.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 222px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPaSyg41u6jThsstQA5XeXiGp4l_ujrcNFnSJDo7k0rZh9R9V4FmNVIw-Yw_eP6SjxLwO2BM9y2gVM_e-YGGOBbVVCT5XfTu7stUjTXPzJIwPz7dkrFXYrRn-n42uYboX-6REwwApiARu-/s320/acceleo_compiler_compliance.png" alt="" id="BLOGGER_PHOTO_ID_5476241920354844066" border="0" /></a></li><li>Those of you that are familiar with the 2.x stream of Acceleo will be pleased to know that Acceleo 3 now provides the same post-processing facilities as its ancestor through the addition of a <span style="font-family:courier new;">post</span> directive on templates. Which allows for the modification of the text generated by a template “after generation”. For example, <span style="font-family:courier new;">post(trim())</span> allows you to properly indent the content of the template while still leaving you the possibility to trim all unnecessary white spaces from the generated text.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifF1tH30VohUldLzIUUWRma3cOepEtnPuMTBl2m1f7FTezYjgnSmTDz4_5hv8vUNI4HelqDO-R_bgplwjVXWdh-XOxi7TBYoGSDiVisKP6jBaoaGY3GHkkZCpVEMGho1qnxKhYTMu4vd-r/s1600/acceleo_template_posttreatment.png"><img style="display: block; margin: 0px auto 10px; text-align: center; cursor: pointer; width: 320px; height: 38px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifF1tH30VohUldLzIUUWRma3cOepEtnPuMTBl2m1f7FTezYjgnSmTDz4_5hv8vUNI4HelqDO-R_bgplwjVXWdh-XOxi7TBYoGSDiVisKP6jBaoaGY3GHkkZCpVEMGho1qnxKhYTMu4vd-r/s320/acceleo_template_posttreatment.png" alt="" id="BLOGGER_PHOTO_ID_5476242530098434914" border="0" /></a></li><li>The “+” operator can now be used whenever one of the operands is a String for concatenation, in order to avoid the verbose <span style="font-family:courier new;">concat(String)</span> OCL offers.</li><li>You can now use properties files to customize your generations through the addition of 4 variants of a <span style="font-family:courier new;">getProperty</span> operation in Acceleo 3. Once again, the operation reference can be looked at for the description of those services.</li><li>We made use of the facilities OCL provides in order to further simplify the navigation language : iterators of our <span style="font-family:courier new;">[for]</span> blocks are no longer mandatory (they'll be implicitly declared if needed and <span style="font-family:courier new;">self</span> can be used in their stead), you no longer need qualified names for your types when the metamodel is declared on the module header (or if it can be inferred from another of the declared metamodels), casting through <span style="font-family:courier new;">oclAsType</span> for all redundant expressions is no longer necessary...</li><li>For those expressions where OCL doesn't allow us to simplify the language, we added <span style="font-style: italic;">non standard</span> operations. For example, <span style="font-family:courier new;">sequence->select(oclIsKindOf(Type)).oclAsType(Type)</span> is obviously redundant, but OCL doesn't allow for this expression not to define the explicit cast. In Acceleo, you can now write <span style="font-family:courier new;">sequence->filter(Type)</span> instead (see also <a href="http://eclipsemde.blogspot.com/2010/05/acceleo-ocl-made-simple.html">my post on this specific issue</a>).</li><li>Acceleo now allows for control characters (<span style="font-style: italic;">\n</span>, <span style="font-style: italic;">\t</span>, <span style="font-style: italic;">\'</span>...) in OCL expressions.</li><li>Acceleo <span style="font-family:courier new;">[for]</span> blocks now declare an implicit “i” variable that can be used to retrieve the iteration count. For example, <span style="font-family:courier new;">[for (Sequence{4, 5, 6})][i/], [/for]</span> will generate <span style="font-style: italic;">1, 2, 3</span>.</li></ul><br /><div style="text-align: center;"><span style="font-weight: bold;">Documentation</span><br /></div>As advertised by Jonathan in one of <a href="http://jomd.blogspot.com/2010/05/acceleo-documentations-are-available.html">his latest posts</a>, the Acceleo documentation is complete and can be accessed from the integrated Eclipse Help through <span style="font-style: italic;">Help => Help Contents</span>, in the <span style="font-style: italic;">Acceleo Model To Text</span> category. We provide everything you need in order to get started with Acceleo; <span style="font-style: italic;">quick start</span>, <span style="font-style: italic;">tutorial</span>, <span style="font-style: italic;">user guide</span>... and the full reference of OCL standard library and Acceleo standard and non standard libraries complete with explanations of the operations and examples.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com0tag:blogger.com,1999:blog-3658502096185788177.post-67774440181800577082010-05-27T04:44:00.000-07:002010-05-27T05:02:33.807-07:00Acceleo : OCL made simpleIt was recently asked on a mailing list how one would order the elements they iterate over in an Acceleo for loop. The elements were UML ControlFlows as in :<br /><br /><blockquote><br />- Package<br />|-- Activity<br /> |-- ControlFlow1<br /> |-- ControlFlow2<br /> |-- ControlFlow3</blockquote><br /><br />The first answer that came to mind, using standard OCL, was :<br /><br /><blockquote>[for (cf:ControlFlow |c.ownedElement->select(a|a.oclIsKindOf(ControlFlow))->sortedBy(e: Element | e.oclAsType(ControlFlow).name))]<br />...<br />[/for]</blockquote><br /><br />Pretty verbose ... If we instead make use of the implicit iterators Acceleo offers, the expression can be simplified to <br /><br /><blockquote>[for (c.ownedElement->select(oclIsKindOf(ControlFlow))->sortedBy(oclAsType(ControlFlow).name))] <br />...<br />[/for]</blockquote><br /><br />But this still sports the redundancy of filtering from a list only the elements of a given type (<span style="font-style:italic;">select</span>) and then casting the elements to ... that very same type (<span style="font-style:italic;">oclAsType</span>). This is due to OCL not allowing Acceleo to infer the return type of the select operation. Starting from Acceleo 3.0, this expression can also be written<br /><blockquote><br />[for (c.ownedElement->filter(ControlFlow)->sortedBy(name))]<br />...<br />[/for]</blockquote><br /><br />Now that's better!Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-65406815177766652112010-04-28T05:32:00.000-07:002010-04-29T11:56:28.775-07:00Acceleo API and properties filesThis post is aimed at anyone that depends on or make use of the Acceleo versions built and provided within the Helios release train, namely 0.9M1-0.9M5 and 3.0M6. If you are not concerned, feel free to ignore it altogether ^^.<br /><br />We added support for ".properties" files in Acceleo in the latest development version (this support appeared for 3.0M1, at the time named 0.9M1). However we realized that this first version of the properties handling left no place for customization/overriding of properties ; no place for internationalization ; and deployment of generation modules as plugins would most likely cause issues with properties lookup. <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=311045">Bug 311045</a> and <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=311068">bug 311068</a> have been opened to track these issues.<br /><br />If you are one of the early adopters that made use of the property support, you'll need to cope with a little change for the M7 build : in the generated class was an "addProperties" method which allowed you to registered the full path to the properties file that was to be loaded. For example if you had a file named "messages.properties" in package "sample" of plugin "org.eclipse.acceleo.sample", you had to register the path "platform://plugin/org.eclipse.acceleo.sample/sample/messages.properties".<br /><br />You will now have to return a list through the method "getProperties" (well, "addProperties" is still there yet deprecated), and this list will have to contain "sample.messages" (that is, <package name>.<file name without extension>) ; and properties file need to be located in source folders.<br /><br />Likewise, if you had set anything as "generated NOT" in the generated launcher, you will have to manually go through some minor API changes as we ended up creating a common superclass for all launchers. Specifically, launchers now "extends AbstractAcceleoLauncher", and what was once private or protected is now mostly public. This means previously generated launchers that had set any method as "generated NOT" might have to enhance the visibility from private to public. Take note that previously generated launchers that have been built and deployed will not fail and can still be used as is, though enabling re-use of your generator can only be done by letting Acceleo regenerate it (or simply code yourself to take these changes into account).<br /><br />Sorry about these changes (especially past M6), but we really thought best to remove the bug-prone behavior instead of trying to maintain it since it had never been released in a stable build. The new API should allow for a real use of property files and enhance the re-usability of any generation module.<br /><br />If you wish to have a look at these changes and cope with them before M7 goes live, they are all accessible in the integration build I201004291415 that went live today (see the <a href="http://www.eclipse.org/modeling/m2t/downloads/?project=acceleo">download page</a> for the <a href="http://www.eclipse.org/modeling/download.php?file=/modeling/m2t/acceleo/downloads/drops/3.0.0/I201004291415/m2t-acceleo-SDK-incubation-I201004291415.zip">zip</a> or <a href="http://www.eclipse.org/modeling/download.php?file=/modeling/m2t/acceleo/downloads/drops/3.0.0/I201004291415/m2t-acceleo-Update-incubation-I201004291415.zip">all-in-one update site</a> downloads).<span style="font-style:italic;"></span><br /><br />If you have any doubt or questions about these issues, feel free to answer the m2t <a href="http://www.eclipse.org/forums/index.php?t=msg&th=167305&start=0&">newsgroup thread</a> I started with a copy of this post.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com1tag:blogger.com,1999:blog-3658502096185788177.post-71924104251068779912010-04-13T06:45:00.001-07:002010-04-13T08:46:33.128-07:00OCL tips and tricks<a href="http://wiki.eclipse.org/Acceleo">Acceleo</a> is entirely based on <a href="http://wiki.eclipse.org/MDT/OCL">OCL (Object Constraint Language)</a> for all of its model navigation syntax. Though we did simplify it as much as possible for Acceleo (getting rid of redundant casts, increasing the standard library, overriding operators, ...), there are still some things that might cause problems to any beginning user.<br /><br />Here are a few of the most unsettling language particularities :<br /><ul><li><p>Operations or features conflicting with reserved OCL keywords (UML anyone?). For example, if your model has a class "Operation" with a feature named "body", then writing "myClass.body" in OCL will result in a somewhat cryptic error : "invalid token 'body'".</p><p>The trick to access such features in OCL is to prefix the feature name with an underscore. For this example, you should have written "myClass._body".</p><p>For the record, the full list of OCL reserved keywords as per the last available OCL version, 3.0, is as follows :<br /></p><ul><li>and</li><li>body<br /></li><li>context</li><li>def</li><li>derive<br /></li><li>else</li><li>endif</li><li>endpackage</li><li>if</li><li>implies</li><li>in</li><li>init<br /></li><li>inv</li><li>let</li><li>not</li><li>or</li><li>package</li><li>post</li><li>pre</li><li>static<br /></li><li>then</li><li>xor<br /></li></ul><p></p></li><li>Accessing enumeration values. This might sound obvious to OCL experts, but how would one compare feature values to set enumerated values? The trick here is to qualify the access. For example if you wish to check that an UML operation's visibility is "public", here is what you would do in Java : "if (operation.getVisibility() == VisibilityKind.PUBLIC".</p><p>The OCL equivalent is "if (operation.visibility = VisibilityKind::public)".</p></li><li>There is no "elseif" in OCL ; remember to close each individual if properly with endifs : "if (...) then ... else if (...) then ... else ... endif endif"</li></ul>I believe these are the most annoying (as in "the most subject to cause weird compilation errors") OCL features ; don't hesitate to add yours :p.Laurent Goubethttp://www.blogger.com/profile/05605492202750997843noreply@blogger.com4