Here is a flash demo being a recap of these features :
jeudi 28 octobre 2010
Here is a flash demo being a recap of these features :
mercredi 13 octobre 2010
Cédric already announced it two weeks ago: MPatch is integrated into EMF Compare!
Did you ever want to transfer changes from one model to another?
Or do you frequently perform the same changes on your models?
MPatch is a technology that stores model changes as self-contained artifacts, just like patches, that are also applicable to other models! Let me show an example of how MPatch works:
This is just a simple model, a base version on the left and a modified version on the right.
Modeled with the IBM Rational Software Architect, but any kind of EMF model is supported.
The changes are highlighted: 3 deleted attributes, 1 updated attribute, 1 new class, 3 new generalizations.
EMF Compare is a nice tool for calculating such changes. The result is shown below.
All changes are nicely highlighted in the treeviews and one can browse through them.
This is where MPatch comes into play: the export menu lists a new option!
An export wizard is started that guides the user through the MPatch creation task.
In the end, the changes are stored in a file, extract_id.mpatch for example.
This file can now be applied to other models, even if their contents differ!
The model below is a different one -- again we want to extract the id attribute into a common superclass.
However, the attributes, the classes, and even the number of attributes and classes differ!
Let's see how MPatch handles the situation.
Selecting Apply MPatch triggers a wizard with the same name.
The crucial part is the so-called resolution of symbolic references -- they are responsible for selecting the proper model elements of your target model.
Let's have a closer look:
- The first change is not applicable because there is no attribute called Title -- ignore this!
- The second change is applicable because a similarly named package (data vs. customerdata) is found -- ok.
- The third change is applicable because I manually selected Contract and Invoice -- ok.
- The fourth change is applicable because similar named attributes (id vs. inv_id / con_id) are found -- ok.
Following the wizard to its end updates the given model and this is the result:
To wrap up, an Mpatch is not only a self-contained patch for models, it is even able to make the changes applicable to different models!
Installation instructions and a lot more information on the project website: http://modeldiff.imm.dtu.dk.
vendredi 1 octobre 2010
mardi 27 juillet 2010
lundi 28 juin 2010
1. because it's including hidden EMF goodness !
2. It provides Class diagram support
Of course the modeling community is way more active than that, I would strongly encourage you to have a small click on this button and have a try on the latest hot contributions which were not part of the Helios release the Agent Modeling Platform :
That's all for today, If I can free more time for this hack I'll provide a diff extension to change the score delta representation to a more meaningfull one, so far it's left as an exercise for the reader ;)
vendredi 18 juin 2010
First, the audience represents many non-commiters (2/3) though the commiters are still quite represented. That's quite consistent with what I was expecting, the survey was published on the planet, some newsgroups and through twitter and as such targeting commiter or adopters following quite closely what's happening in Eclipse Modeling.
- People are not even aware of these books or books are old fashioned now : all content should be on the web !
- It's so hard to understand what each project is providing that one really needs some Modeling Guide.
- As a user you always want doc even if you won't ever read it, it just gives you the confidence that the technology is not going to vanish in a glimpse.
- [ ] <----- any opinion expressed through the comments
mercredi 9 juin 2010
mercredi 28 avril 2010
vendredi 26 mars 2010
- Many people are using EMF Compare. That should not be a surprise as it provides a key feature for anybody working with models, but still it gives me a warm feeling :) The ECon attendees provided me a lot of very relevant feedback, among others it looks like scability is not so nice when one is using a big model. Don't worry, I'll work on that (In fact I already started) and you can expect a performance boost, even for the generic engine. More of that in a future blog post with figures.
- People are now used to the idea of e4 is going to exist, it will provide new means for writting application, I also have the feeling that people understood that e4 is going to be what WE as a community, wants it to be.
- Chocolate fountains are not mandatory, but some bugs will always arise.
- ATL is definitely THE model to model transformation language, it's mature, and now thanks to William's work the tooling is a bit closer to the perfection.
- CDO is one of the most amazing framework I had the change to use, it's quite unbelivable that such a small and slim framework can provides you such a power. You need years of engineering and professionalism to achieve this. congrats to the whole CDO Team !
- I have a lot of hope for the Mylyn Review project, the approach is simple but perfect for people like me, it will just be "yet another key feature" of the IDE. In fact the whole Mylyn project is providing, as usual, innovations.
- The Sharks Rocks ! They blasted the Dallas Stars ! And I guess I'll be more interested about hockey now :)
- Pascal has not been abducted by aliens, he is still the same although being transformed in a Maven guy now.
- Modeling is everywhere. It's just pervading on everything : from your IP Log to the next generation platform you'll rely on.
- End users really appreciated the work I did on the modeling package, Here again, thanks for your feedback.
- Xtext was everywhere, and will be a key asset for the upcoming IDE generation.
- The Eclipse Foundation did a tremendous work for this event, and it' s been perfect ! Thanks again !
- Acceleo is so powerful that many people expressed their wish to use it for their code generation needs : step one on the "taking over the world" plan is validated.
- Nasa, Rockets and Robots are cool.
- The Architecture Council is taking more and more initiative and Martin is doing a great job driving it.
- Now that EMF is everywhere everybody wants to use EEF
- Huge companies like SAP or Thales are building their tooling strategy around Eclipse - not only as a platform but also as a community.
- I already said "No" to my manager at least two times !
- Such a conference in an hotel can work, and it's actually even better than in a Convention Center, we have nice couch, a bar, it makes discussion way easier.
- Having tutorials in the morning during the whole week is great, then you start smoothly, learn things and code : I can fill my addiction.
- It's possible to create a conference program of high quality (the best I had in the previous four years to my opinion), with such a diverse community. Kuddos to Oisin !
mardi 23 mars 2010
This talk will tackle team-working with models. Once you use models in your development proces, they matters as much as the source code. Don't you want to be able to diff, merge or even patch your models just like with text files ?
The good news is that unlike text files models have a semantic structure defined thanks to their ecore model, as such we're able to semantically compare the models, comparing the serialization (XMI or other..) is often meaningless.
By the way I'm the project lead of EMF compare, the project has been contributed in Eclipse in early 2007, at that time many EMF adopters realized that this piece was missing in the Modeling ecosystem and this lack was often a blocker !
So here we are, three years later. EMF Compare - in the EMF Technology project at first- graduated and is now part of the EMF project itself !
Just like Transaction, Validation or CDO, Compare is one of the many pieces you can reuse as a framework, or just as a tool. Its focus is quite narrow : comparing, merging and patching any kind of EMF model, the later being an UML model or a domain specific one.
As we graduated we've been focusing on keeping stable API you can rely on. We really think that EMF popularity is highly due to the fact that depending on it is easy as it is completely forward compatible. Working nicely as a pure Java jar library is another key asset of EMF, we tried to stick to that for the Compare project: our framework can be used as a Java jar, not depending on Equinox or any extension point.
We could phrase the Eclipse IDE spirit in : be extensible, be customizable, be integrated. We are sticking to this motto too, you can extend or customize any part of the comparison process.
The compare and merge features are completely integrated with the Eclipse Team API. When you launch a comparison from the workspace or from an history, if the file is in fact a model, EMF Compare will be opened and will show you the differences, allowing you to merge, or switch back to the serialization diff.
Let's have a look on the tool through a demo. This demo goes higher and higher in coolness, as such it's starting by comparing an old fashioned UML model on a dying CVS Repository.
A bit more cool : comparing a domain specific model on a SVN repository.
Total coolness : comparing an XText DSLsemantically, merging it, on top of a GIT repository !
That's just the tip of the iceberg, EMF Compare has a few more features and is especially useful in a lot of contexts, rather than listing all these details I'll focus now on the inside, revealing you which kind of magic make this clock ticking.
As I said at the beginning, the good news comparing models is that we've got semantic information we're not comparing plain text. There is a drawback though: models are graph and as such being able to match similar graphs is a complex and tricky problem.
The first thing we have to do for a comparison is to match the elements from both versions of the model.
For a given element this engine will extract it's type information, the content values, its relations with other elements and its name if we can detect one. Each piece of this extraction will be compared with other elements to compute a similarity coefficient, from this one we can try to get closer and closer to the perfect match.
Once this engine has done it's job, it provides a Match Model grouping all this information and weaving the other models.
It gets more complicated, (and then more interesting) when using source control management systems. Then you have to match three versions of a model: yours, the remote one, and the common ancestor between those versions.
To do so we builds two match models, between your local version and the common ancestor, then between the remote version and the common ancestor, and we combine those two match models into one, weaving the three models altogether.
At this stage it should be obvious that the faster the match engine is, the faster you'll get a result.
To be honest the generic match engine is not so fast, having little clue about the models it's matching it spends a lot of time browsing the structure, trying to match things which probably have no possibilities of being the same..
Being aware of that we eased the definition of your own match engine specific to your Ecore model. In doing so no doubt you'll get better results and way faster.
Let's take a step back. What are we trying to do ?
In fact, when you have the MatchModel, deducing the DiffModel is not a huge task, you basically have to browse the matched elements, checking for changed attributes and reference, and then create for each "unmatched element" the corresponding deletion or addition event.
Here again, you can plug in your own diff engine, and you can even define your own diffs specific to your formalism. Instead of having a "stock value changed from 12 to 34" event you can define yours as being "stock value has been increased from 12 to 34" and even aggregate several atomic diffs in a single top-level one.
Now you should have a basic understanding of what EMF compare is trying to solve and in which way. We've seen that stability both in term of API and code was our primary goal right now but does that means nothing new is being done in Compare ?
For Helios we fixed many issues thanks to the community feedback, support for fragmented models and matching of referenced resources has been greatly improved.
The primary feedback is bug reports, but we also had quite a few contributions among those a new API to scope the matching process and a whole new set of plugins to create model independent diffs resilent to transformations in the model you want to apply the diff on.
So many things to discuss in such a short time frame.
Want's more ? Have a try downloading the Eclipse Modeling Package !