Re: [emft-dev] Contribution to EMF-Compare as a Master's Thesis

[Cédric Brun <cedric.brun@xxxxxxx>]

Hi Tobias,

I checked your prototype, it seems to work quite nicely already, I think 
that's a nice start and it proves this kind of usage for GMF is possible. 
I won't speak about namespaces and stuffs like that in the java code, I'll keep 
consider this as a proof of concept ;)
 
Anyway, what kind of user interaction were you considering,diagram at the top, 
and then list of differences at the bottom ? On proprietary tools you often get 
two diagrams at the bottom (both versions) and specific markers to show "see ! 
this element is missing". How is the user supposed to merge ?
Please keep in mind that you can quite easily get more than one diagram in a 
single file now with GMF. As Such the user should be able to switch diagram or 
pick the good one.

Cédric

On Friday 11 July 2008 08:48:38 Tobias Jähnel wrote:
> Hi Cédric,
>
> I'm sorry I'm a bit late. I wanted to answer you last week, but there
> were more problems in implementation and I had less time than I
> expected.
>
> Now I've finished a first prototype to show you my ideas.
> You can find it here: http://www.jonmedia.net/GraphicalEMFCompare.zip
>
> I simply exported the projects from Eclipse, so please import them
> into a workspace. I've only tested it with Ganymede.
> Beside the compare PlugIn you find a GMF editor for the shapes Example
> (Examples->My Diagram in New file wizard). Use only this editor,
> because by now I can only compare models, where the business model and
> the notation model are in the same file.
> Also, only use the "Compare to local History" item to start the
> compare viewer, because I haven't implemented/tested other methods
> yet.
>
> If something is not working please let me know. You can also talk to
> me on IRC (jfbtoby) or Jabber (my E-Mail Address).
> I'm looking forward to getting feedback from you.
>
> Toby
>
> On Fri, Jun 27, 2008 at 4:02 PM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> > Hi Tobias,
> >
> > This looks great to me,  the GMF team could probably provide some input
> > about the design you provided and confirm this is a good solution.
> >
> > Cheers,
> >
> > Cédric
> >
> > On Thursday 19 June 2008 15:52:07 Tobias Jähnel wrote:
> >> Hi Cédric,
> >>
> >> as promised I send my design ideas for discussion now.
> >> Please read through it and tell me what you think about it.
> >> I'm not sure if everything is practicable as I think but I'm open to
> >> improvements and other ideas.
> >>
> >> I'm sure, that details will change while development, but I want to
> >> have a concrete direction, so that I can start coding next monday if
> >> possible.
> >>
> >> I didn't want to send attachments over the list, so I uploaded it.
> >> Here it is: http://www.jonmedia.net/DesignApproach.pdf
> >>
> >> Toby
> >>
> >> On Fri, Jun 13, 2008 at 12:11 PM, Tobias Jähnel <tjaehnel@xxxxxxxxx> 
wrote:
> >> > Hi Cédric,
> >> >
> >> > there is not so much to "see", yet. :)
> >> > I will try to send you design concepts next week.
> >> >
> >> > As regards the Documentation: I am able to use the EMF-Compare API and
> >> > understand most of what goes on.
> >> > Though a documentation of the Meta-Models would be very helpful, since
> >> > this is where the graphical representation must be based on.
> >> > Oherwise I have to try out myself how changes in the models are
> >> > reflected in the match- and diffmodel. If there is already some
> >> > partial documentation, perhaps you could send it to me.
> >> >
> >> > Thanks
> >> > Toby
> >> >
> >> > On Thu, Jun 12, 2008 at 1:51 PM, Cédric Brun <cedric.brun@xxxxxxx> 
wrote:
> >> >> Hi Tobias,
> >> >>
> >> >> I'm eager to see a bit more about what you've done so far :)
> >> >>
> >> >> The EMF Compare RC4 bits contains more documentation, a quick
> >> >> overview of the architecture and developer information about re-using
> >> >> the EMF Compare services.
> >> >> If you need more documentation on a specific point (like describing
> >> >> the metamodels) we can try to emphasize our work on these points, so
> >> >> please tell us.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Cédric
> >> >>
> >> >> On Thursday 12 June 2008 13:28:42 Tobias Jähnel wrote:
> >> >>> Hi,
> >> >>>
> >> >>> I just want to give you an update on my current work.
> >> >>>
> >> >>> It took me very much time to get into the details of EMF/GEF/GMF,
> >> >>> which are interesing for me. (What are EditParts, Figures, Viewers,
> >> >>> what do they do, which Factory is used by whom etc.) Now I've
> >> >>> (finally) managed displaying two graphs side-by-side when I use the
> >> >>> "Compare to..." action in Eclipse. The graphs looks the same as they
> >> >>> look in the GMF-editor.
> >> >>>
> >> >>> At the moment I'm going into depth of EMF compare. Is there really
> >> >>> no documentation? I couldn't find any UML-charts or documentation
> >> >>> other then the javadoc (almost same with GMF). By now a have a rough
> >> >>> overview of how things work together, but there are still many
> >> >>> things I'm not sure about. Examples are the diffmodel and the
> >> >>> matchmodel. Some elements are quite self explaining, but many are
> >> >>> not (for me).
> >> >>>
> >> >>> I already have some specific design-approaches in mind, but I will
> >> >>> make them more concrete before I present them to you for discussion.
> >> >>>
> >> >>> Toby
> >> >>>
> >> >>> On Wed, Apr 30, 2008 at 1:57 PM, Cédric Brun <cedric.brun@xxxxxxx>
> >
> > wrote:
> >> >>> > Hi Tobias and Jan,
> >> >>> >
> >> >>> > Many issues you are refering to here are already tackled by the
> >> >>> > EMF Compare component itselft, model merging and differencing can
> >> >>> > be specialized for a given metamodel and a generic implementation
> >> >>> > is provided which fits nicely with human understandable metamodels
> >> >>> > (aka not UML  ;) ) . Every aspect link to the merging, elements
> >> >>> > UUID or Ecore Id's, is the responsability of the compare service
> >> >>> > we provides.
> >> >>> >
> >> >>> > Tobias's work seems more focused on the graphical representation
> >> >>> > of these diffs once EMF compare gave him the diff model. My
> >> >>> > opinion is that the integration with the graphical modeler should
> >> >>> > not impact it's code. GMF/GEF brings many way to dynamically
> >> >>> > extends the modeler graphical aspects or behavior through the
> >> >>> > editpart and edit policies providers.
> >> >>> >
> >> >>> > I agree the decorator service will not fit to address the needs
> >> >>> > here. May be you should start by developping a prototype for a
> >> >>> > given graphical modeler (the one from Ecore tools for instance )
> >> >>> > in a specific plugin and see how far you can go corresponding to
> >> >>> > what you want to achieve.
> >> >>> >
> >> >>> > Cédric
> >> >>> >
> >> >>> > Le Wednesday 30 April 2008 12:49:16 Jan Köhnlein, vous avez écrit :
> >> >>> >> Hi Tobias
> >> >>> >>
> >> >>> >> nice idea, I've been thinking about doing something similar but
> >> >>> >> never really found the time.
> >> >>> >>
> >> >>> >> Just some thoughts from my side.
> >> >>> >> Theoretical issues:
> >> >>> >> * It's a common understanding that model merging (and therby
> >> >>> >> diffing) is something domain (metamodel) specific, e.g. it
> >> >>> >> depends a lot on the concrete syntax. It is likely you won't
> >> >>> >> satisfy everyone with your solution.
> >> >>> >> * Note that most UML2 tools only provide poor solutions for model
> >> >>> >> diff/ merge. I don't want to say it's impossible, but there
> >> >>> >> doesn't seem to be an easy solution especially for the generic
> >> >>> >> case. Maybe you have to restrict it to (some) explicit scenarios.
> >> >>> >> * Diagrams only show parts of a semantic model. How do you deal
> >> >>> >> with the invisible diffs?
> >> >>> >> * A diff might need a different metamodel, e.g. changed
> >> >>> >> multiplicities * What kind of differences do you want to show
> >> >>> >> wrt. ecore?
> >> >>> >>
> >> >>> >> Technical issues:
> >> >>> >> * One of the major problems is how to get two models aligned.
> >> >>> >>    * Consider using UUIDs for the model elements
> >> >>> >>    * One idea was to preprocess the two models and merge them
> >> >>> >> into one with annotated elements. This should have less impact on
> >> >>> >> the generated GMF code.
> >> >>> >>    * Maybe it's easier to override the "getSemanticChildren"
> >> >>> >> methods of specific EditParts to return elements from both
> >> >>> >> models. * Don't wrap the EditParts but add additional
> >> >>> >> EditPolicies that change properties of the shapes. This is far
> >> >>> >> more GMF/GEF like.
> >> >>> >>
> >> >>> >> Good luck
> >> >>> >> Jan
> >> >>> >>
> >> >>> >> Am 30.04.2008 um 11:33 schrieb Tobias Jähnel:
> >> >>> >> > Hi,
> >> >>> >> >
> >> >>> >> > fist of all I don't know if this list is the right place for
> >> >>> >> > discussing my concepts. If not, please point me to the right
> >> >>> >> > place.
> >> >>> >> >
> >> >>> >> > What do I want to do in my Master's Thesis?
> >> >>> >> > Create a diff viewer for EMF models using EMF compare, which
> >> >>> >> > goes beyond the current tree structure.
> >> >>> >> > This actually means displaying the model with edges and nodes
> >> >>> >> > using draw2d figures.
> >> >>> >> > Since the EMF model itself does not contain any information
> >> >>> >> > about the graphical representation,
> >> >>> >> > ideally any editor which is created or will be created using
> >> >>> >> > GMF, should be able to serve as the base.
> >> >>> >> >
> >> >>> >> > Goals would be as follows:
> >> >>> >> > 1 make use of any GMF editor to draw shapes and modify them
> >> >>> >> >  (e.g. dotted lines, various colors) to show deleted, added and
> >> >>> >> >   modified nodes/connections in a convenient way.
> >> >>> >> > 2 enable the creator of the GMF editor to override those
> >> >>> >> > defaults and define how deleted/added/edited nodes and
> >> >>> >> > connections should look
> >> >>> >> >
> >> >>> >> > I think this might be too much work for my Thesis, because
> >> >>> >> > there is more than this to do.
> >> >>> >> > But I can definitely do parts of it.
> >> >>> >> >
> >> >>> >> > After some weeks of getting familiar with EMF, GMF and GEF, my
> >> >>> >> > idea to achieve
> >> >>> >> > this is as follows:
> >> >>> >> > - Use the EditPartFactory, which has been registered for the
> >> >>> >> > editor, to fetch the EditParts
> >> >>> >> > - Wrap my own EditParts around the original EditParts
> >> >>> >> > (decorator pattern)
> >> >>> >> >  I can now change the original look of the shapes.
> >> >>> >> > - For Goal 2 a new extension point can be introduced. I haven't
> >> >>> >> > thought so much
> >> >>> >> >  about this yet, because it should not be the big problem
> >> >>> >> >
> >> >>> >> > The reason I chose not using the decorator approach of GMF
> >> >>> >> > (DecoratorProvider) is, that it does
> >> >>> >> > probably not fit the requirements. The documentation says, that
> >> >>> >> > it is inteded to decorate the shapes by
> >> >>> >> > drawing something like an overlay on top of the shape. But I
> >> >>> >> > want to change the look of the shape
> >> >>> >> > itself. I read somewhere on the net, that it is possible to
> >> >>> >> > fetch the edit part from the decorator and
> >> >>> >> > modify the figures directly. If this is right, it would
> >> >>> >> > probably be a better approach than mine.
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > Thank you for your attention. :)
> >> >>> >> >
> >> >>> >> > Please tell me what you think about my ideas. Please also tell
> >> >>> >> > me if this is not practible, conflicts
> >> >>> >> > the design of GMF etc., this is not what you need or you don't
> >> >>> >> > like it for any other reason.
> >> >>> >> > Any suggestions are welcome because I'm new to EMF, GEF and
> >> >>> >> > GMF.
> >> >>> >> >
> >> >>> >> > :)
> >> >>> >> >
> >> >>> >> > Toby
> >> >>> >> >
> >> >>> >> > PS.: I've found a way to come into IRC at work now. If it's
> >> >>> >> > easier to discuss things directly rather than email, my name is
> >> >>> >> > "jfbtoby" there.
> >> >>> >> >
> >> >>> >> > On Wed, Apr 16, 2008 at 1:36 PM, Tobias Jähnel
> >> >>> >> > <tjaehnel@xxxxxxxxx>
> >> >>> >> >
> >> >>> >> > wrote:
> >> >>> >> >> Hi Cédric,
> >> >>> >> >>
> >> >>> >> >> thank you for your suggestions.
> >> >>> >> >> In fact the first one is the most interesting for me, so I
> >> >>> >> >> decided to go into this topic.
> >> >>> >> >> I sent an e-mail to my professor to ask him if this is an
> >> >>> >> >> option, but I haven't got a response yet. Though I don't think
> >> >>> >> >> there will be any problems.
> >> >>> >> >>
> >> >>> >> >> Unfortunately I cannot come into IRC. All IM protocols,
> >> >>> >> >> including IRC,
> >> >>> >> >> seem to be blocked by the proxy of the company (only ICQ is
> >> >>> >> >> working).
> >> >>> >> >>
> >> >>> >> >> Could you go a bit deeper into what you expect?
> >> >>> >> >> When you write "... and integration in graphical modelers", do
> >> >>> >> >> you think of any concrete graphical modelers available?
> >> >>> >> >> I think there should be an easy way to integrate with any
> >> >>> >> >> modeler.
> >> >>> >> >>
> >> >>> >> >> Toby
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> On Thu, Apr 10, 2008 at 7:02 PM, Cédric Brun
> >> >>> >> >> <cedric.brun@xxxxxxx>
> >> >>> >> >>
> >> >>> >> >> wrote:
> >> >>> >> >>> Hi Tobias,
> >> >>> >> >>>
> >> >>> >> >>> Any kind of contribution is obviously welcome!
> >> >>> >> >>>
> >> >>> >> >>> It really depend on your own interests but here are the
> >> >>> >> >>> challenges I can think
> >> >>> >> >>> of  (both intellectualy and practically interesting) :
> >> >>> >> >>>
> >> >>> >> >>> * Differences representation and integration in graphical
> >> >>> >> >>> modelers : this one
> >> >>> >> >>> is tricky in the sense that we did not figured out yet what
> >> >>> >> >>> is the best
> >> >>> >> >>> representation of differences for the end user. That's part
> >> >>> >> >>> of the reason why
> >> >>> >> >>> we define many API so that other plugins may refactor the way
> >> >>> >> >>> differences are
> >> >>> >> >>> kept and displayed. The user quickly ends up with many
> >> >>> >> >>> differences and the
> >> >>> >> >>> classical hierarchical way of representing models doesn't fit
> >> >>> >> >>> with the user
> >> >>> >> >>> expectations, there's obviously room for improvements.
> >> >>> >> >>>
> >> >>> >> >>> Correlated to this subject is "how we can visualize
> >> >>> >> >>> differences in a graphical
> >> >>> >> >>> modeler", it's not a technical concern as it doesn't seems
> >> >>> >> >>> like GMF is a
> >> >>> >> >>> blocker for that, it's more, there again, about what we need
> >> >>> >> >>> to display,
> >> >>> >> >>> where, and how, to help the user manage the model evolutions.
> >> >>> >> >>>
> >> >>> >> >>> The Ecore Tools guys want to integrate emf compare in the
> >> >>> >> >>> Ecore modeler, this
> >> >>> >> >>> could be a nice testbed for ideas concerning the graphical
> >> >>> >> >>> representations.
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >>> * Huge models management : the current implementation of the
> >> >>> >> >>> GenericMatchEngine is not able to handle huge models, (by
> >> >>> >> >>> huge models I mean
> >> >>> >> >>> more than 1GB ones) because the principles and algorithms are
> >> >>> >> >>> just not rights
> >> >>> >> >>> for such data. Another interesting subject could be to
> >> >>> >> >>> provides an alternative match engines for such models.
> >> >>> >> >>>
> >> >>> >> >>> That's two subjects I can think of but of course it's up to
> >> >>> >> >>> you, just to let
> >> >>> >> >>> you know on the "research" side we'll work in the following
> >> >>> >> >>> month with the
> >> >>> >> >>> Aquila University (Italy) on a model representation of the
> >> >>> >> >>> differences
> >> >>> >> >>> (models changeset/patch) providing the same features as the
> >> >>> >> >>> textual patch
> >> >>> >> >>> format (with fuzzy searchs and stuffs like that) but all the
> >> >>> >> >>> other areas are
> >> >>> >> >>> opened for experimentation :)
> >> >>> >> >>>
> >> >>> >> >>> In a nutshell, the first subject I described seems to fit
> >> >>> >> >>> quite nicely with
> >> >>> >> >>> your "part 2", the second one is just another area in which
> >> >>> >> >>> we know we have
> >> >>> >> >>> some progress to do but whatever you want to focus on we
> >> >>> >> >>> would gladly help
> >> >>> >> >>> you !
> >> >>> >> >>>
> >> >>> >> >>> You can use this mailling-list or come on the
> >> >>> >> >>> #eclipse-modeling IRC chan for
> >> >>> >> >>> live discussions, Laurent is "Kellindil" there and I'm
> >> >>> >> >>> "Tortoose".
> >> >>> >> >>>
> >> >>> >> >>> Cheers,
> >> >>> >> >>>
> >> >>> >> >>> Cédric
> >> >>> >> >>>
> >> >>> >> >>> Le Thursday 10 April 2008 11:05:54 Tobias Jähnel, vous avez
> >> >>> >> >>> écrit
> >> >>> >> >>>
> >> >>> >> >>>> EMF Compare developers,
> >> >>> >> >>>>
> >> >>> >> >>>> I am Tobias Jaehnel, student of Computer Science in
> >> >>> >> >>>> Nuremberg, Germany.
> >> >>> >> >>>>
> >> >>> >> >>>> I'm going to start my Master's Thesis and I'm interested in
> >> >>> >> >>>> contributing to the EMF-Compare project.
> >> >>> >> >>>>
> >> >>> >> >>>> Background:
> >> >>> >> >>>> The topic I have chosen for my thesis it based on a
> >> >>> >> >>>> state-chart editor, which uses EMF and GEF. This editor has
> >> >>> >> >>>> been developed in the
> >> >>> >> >>>> company I'm working for, for very particular needs. My
> >> >>> >> >>>> thesis should
> >> >>> >> >>>> be divided into two parts.
> >> >>> >> >>>>
> >> >>> >> >>>> Part 1: Design and Implementation of an algorithm to find
> >> >>> >> >>>> the differences between two state charts
> >> >>> >> >>>> Part 2: Visualizing the differences in one or two ways,
> >> >>> >> >>>> which are convenient for the user
> >> >>> >> >>>>
> >> >>> >> >>>> After some research I found EMF Compare, which fits our
> >> >>> >> >>>> requirements
> >> >>> >> >>>> and entirely covers Part 1.
> >> >>> >> >>>> Since I do not want to reinvent the wheel but are still very
> >> >>> >> >>>> interested in this topic, I'm looking for some other
> >> >>> >> >>>> challenge now.
> >> >>> >> >>>>
> >> >>> >> >>>> Can you think of a component or topic I could develop for
> >> >>> >> >>>> you? I actually want to keep Part 2, but I would appreciate
> >> >>> >> >>>> it, if I could
> >> >>> >> >>>> make a contribution to EMF Compare in addition.
> >> >>> >> >>>>
> >> >>> >> >>>> Thanks in advance.
> >> >>> >> >>>>
> >> >>> >> >>>> Regards,
> >> >>> >> >>>> Toby
> >> >>> >> >>>> _______________________________________________
> >> >>> >> >>>> emft-dev mailing list
> >> >>> >> >>>> emft-dev@xxxxxxxxxxx
> >> >>> >> >>>> https://dev.eclipse.org/mailman/listinfo/emft-dev
> >> >>> >> >>>
> >> >>> >> >>> _______________________________________________
> >> >>> >> >>> emft-dev mailing list
> >> >>> >> >>> emft-dev@xxxxxxxxxxx
> >> >>> >> >>> https://dev.eclipse.org/mailman/listinfo/emft-dev
> >> >>> >> >
> >> >>> >> > _______________________________________________
> >> >>> >> > emft-dev mailing list
> >> >>> >> > emft-dev@xxxxxxxxxxx
> >> >>> >> > https://dev.eclipse.org/mailman/listinfo/emft-dev
> >> >>> >>
> >> >>> >> --
> >> >>> >> Dr. Jan Köhnlein
> >> >>> >> Senior Software Architekt
> >> >>> >>
> >> >>> >> Telefon: +49 (0) 431 / 5606-337
> >> >>> >> Telefax: +49 (0) 431 / 5606-339
> >> >>> >>
> >> >>> >> http://www.itemis.de
> >> >>> >> jan.koehnlein@xxxxxxxxx
> >> >>> >>
> >> >>> >> itemis AG
> >> >>> >> Schauenburgerstr. 116
> >> >>> >> 24118 Kiel
> >> >>> >>
> >> >>> >> Rechtlicher Hinweis:
> >> >>> >>
> >> >>> >> Amtsgericht Dortmund, HRB 20621
> >> >>> >>
> >> >>> >> Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
> >> >>> >>
> >> >>> >> Aufsichtsrat: Prof. Dr. Burkhart Igel (Vors.) Stephan Grollmann,
> >> >>> >> Michael Neuhaus
> >> >>> >>
> >> >>> >>
> >> >>> >> _______________________________________________
> >> >>> >> emft-dev mailing list
> >> >>> >> emft-dev@xxxxxxxxxxx
> >> >>> >> https://dev.eclipse.org/mailman/listinfo/emft-dev
> >> >>> >
> >> >>> > _______________________________________________
> >> >>> > emft-dev mailing list
> >> >>> > emft-dev@xxxxxxxxxxx
> >> >>> > https://dev.eclipse.org/mailman/listinfo/emft-dev
> >> >>>
> >> >>> _______________________________________________
> >> >>> emft-dev mailing list
> >> >>> emft-dev@xxxxxxxxxxx
> >> >>> https://dev.eclipse.org/mailman/listinfo/emft-dev
> >> >>
> >> >> _______________________________________________
> >> >> emft-dev mailing list
> >> >> emft-dev@xxxxxxxxxxx
> >> >> https://dev.eclipse.org/mailman/listinfo/emft-dev
> >>
> >> _______________________________________________
> >> emft-dev mailing list
> >> emft-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/emft-dev
> >
> > _______________________________________________
> > emft-dev mailing list
> > emft-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/emft-dev
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev