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

["Tobias Jähnel" <tjaehnel@xxxxxxxxx>]

Hi Cédric,

it's great that my prototype works.
As for namespaces and stuff, I've no idea about coding style and
namespace guidelines in eclipse projects. But I think that's one thing
easy to change.

I think merging should work the same way as in the text-compare and
the EMF-Compare GUI.
I actually tried to get away this ContentMergeViewer at the bottom to
only show the merged diagram indicating the changes. But I like the
idea to display both models at the bottom instead. I just suspect,
that this design would take too much space and the user has to do very
much scrolling.

I'm not sure what you mean with multiple models in one file. I haven't
seen files with more than one notation model. I know, that one
notation model could reference elements from more than one business
model, but there is no reason to switch.

Toby


On Tue, Jul 15, 2008 at 9:53 AM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev
>