[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emft-dev] Contribution to EMF-Compare as a Master's Thesis
|
Hi,
I didn't know about the sub-model capability. I think we should not do
everyting "at once", since my thesis time is limited. I suggest at
first not caring too much about sub-models, but adding this feature
later.
Toby
On Tue, Jul 15, 2008 at 1:23 PM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> My answers are inline ..
>
>> 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.
>
> Yep, we'll consider that when merging the final contribution :)
>
>> 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 agree, models at the bottom would be better imho.
>
>> 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.
>
> Yes it's possible to get more than one notation model in a given resource, it
> happens when your modeler is designed with sub-diagraming (ou double click an
> element and then a sub diagram gets created. As it's supported by GMF I think
> we should handle it and then provide a way for the user to consider one
> diagram or the other.
>
> At some point the user will probably need the common interaction he has with
> diagrams like zooming, or may be searching. That's also something to keep in
> mind.
>
> Cédric
>
>
>> 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
>>
>> _______________________________________________
>> 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
>
