[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[emft-dev] [EMF Compare] Diagram tools set up
|
I'm not sure if this should be on forums or mailing list.. anyway a question on project setup:
For emf.compare.ui.gmf I've got dependency issues..
org.eclipse.gmf.ecore.editor, (not resolved)
org.eclipse.gmf.runtime.draw2d.ui;bundle-version="2.1.0", (version too high)
I'm just using Indigo GMF which is just at 1.5 so obviously there is a big gap there. I've tried the usual suspects for update sites, but no joy, as they seem to be built for Helios and are looking for sites that aren't available.
I checked out the contributor docs but couldn't find anything on this.
thanks,
Miles
On Jul 19, 2011, at 1:43 AM, Mariot Chauvin wrote:
> Hi Miles,
>
> About how can we embellish or hide model elements without interfering with the kind of quasi-semantic information, you may have a look to what is being done on EMF Compare for diagram comparison : http://wiki.eclipse.org/EMF_Compare/GMF_Compare_Markers
>
> Regards,
>
> Mariot
>
> Le 18/07/2011 19:27, Miles Parker a écrit :
>> Thanks Hemery and Gerard. That's very helpful. One clarification -- despite GEF being in Modeling there aren't any direct dependencies between GEF and EMF I don't think. But as long as a GEF implementor adapts an editing domain for the digram and an EObject for diagram elements that works out fine. I think I'm going to go with an approach that generalizes that way whenever possible, but then to actually modify the digram I'll want to make use of or provide some lightweight API and/or GMF, otherwise we'll be guessing about what's appropriate to highlight a specific digram element. And actually, on working with it, I found that GMF requires you to use the backing model for all changes; if you try to work with the GEF directly it gets overridden. I may paly around with a separate layer for that. And thanks also for the note about Top-Cased requirements. Other examples form the modeling community of annotating or modifying user diagrams would be most helpful...
>>
>> On that note, one bugzilla I could really use feedback from the modeling diagram community one issue I could really use ideas from the diagram community on: https://bugs.eclipse.org/bugs/show_bug.cgi?id=343218#c2 The issue is, how can we embellish or hide model elements without interfering with the kind of quasi-semantic information that is encoded into diagrams, i.e. coloring, fonts, etc.. (I won't even discuss positioning/layout here..)
>>
>> I'd also really like to support tree editors reasonably well if at all possible. There are some issues with figuring out how that will work with EMF Item Providers. I'm thinking that maybe an adapter approach can work there. One big reason for doing that is so that we can get the EcoreTools in Project Manager outline to be integrated. The Mylyn Java tools support similar features for Java members. (One thing I can't figure out is why EcoreTools only provides this feature for the Project but not the Package Explorere. Does anyone use the Project Explorer? :))
>>
>> One tool that Hemery missed that I think is really cool... MoDisco demoed their query based dynamic EMF editor at EclipseCon. Actually, it's not quite a tree editor, there is a forms component too. And mentioning Forms, we can't leave EEF out, but that won't be a target or this round.
>>
>> cheers,
>>
>> Miles
>>
>> On Jul 18, 2011, at 1:06 AM, HEMERY Vincent wrote:
>>
>>> Hello Miles,
>>>
>>> The relation between EcoreTools and MDT-Papyrus is very simple : none
>>> but GMF.
>>> These are two separate tools based on the same GMF technology.
>>> MDT-Papyrus currently has no editor for Ecore models. MDT-Papyrus
>>> currently focuses more on UML and SysML diagrams. Moreover, I doubt they
>>> (we) will develop one soon, since we have other mature tools for editing
>>> Ecore models.
>>>
>>> If you want to be sure to cover almost all the existing editors, you
>>> will have to support EMF, GEF, and GMF editors (GMF is based on GEF
>>> which is based on EMF).
>>> Yet, for the moment, here are the editors I know or I have used so far
>>> to edit Ecore models :
>>> - EcoreTools (GMF-based editor)
>>> This should be the favorite editor for end-users.
>>> - GMF example editor for EcoreTools (GMF-based naturally)
>>> It may be used by some people who do not know EcoreTools, but
>>> - EMF tree-based editors :
>>> - Sample Ecore Model Editor,
>>> - Sample reflective Ecore Model Editor,
>>> - Acceleo Reflective Editor ...
>>>
>>> EcoreTools used to be a GEF editor generated with TOPCASED, but it has
>>> been completely refactored to be based on GMF. Hence, all is left now
>>> for editing Ecore models (as far as I know) are GMF and EMF-based editors.
>>>
>>> Of course, you can try and support EMF editors and GEF editors, but I
>>> doubt they will be used by end users. I personally use EMF tree-based
>>> editors when I want to have direct access to the file content, for
>>> developement purpose, like I use a text editor.
>>> So, most probably, supporting all GMF editors will be sufficient as far
>>> as Ecore is concerned.
>>>
>>> If you want to have a look on an example, I have already worked on a
>>> tool now supporting GEF editors (TOPCASED editors), MDT-Papyrus GMF
>>> editors and EcoreTools editors. This tools is used for requirement
>>> traceability and relies on drag and drop on diagram elements. It is
>>> named TOPCASED-Requirements.
>>> The tool is open-source, so you can inspire on it if you just need
>>> samples. It has a "core" feature, depending on none of the above
>>> editors, and specialized features enabling it for each of the mentioned
>>> editors. You will find information about were to find the sources on
>>> http://gforge.enseeiht.fr/scm/?group_id=112
>>>
>>> If you need extra information on it, you can still contact me directly.
>>>
>>> Vincent.
>>>
>>> Le 14/07/2011 20:26, Miles Parker a écrit :
>>>> Yes, of course! :) I think what I'm wondering is -- sorry for my
>>>> ignorance -- how are those tools related to the Papyrus EMF tools? I see
>>>> from the project page that there is overlap between them. (And then how
>>>> is that related to the UML2, SysML and other "M2" kind of modeling
>>>> projects?) Are these all GMF based or is the Ecore tool more pure GEF
>>>> like the other EcoreTools editors? And are there any other toolsets out
>>>> there or planned that I might be missing? Basically, I'm looking for the
>>>> best lever point that will serve the needs of the most toolsets and if I
>>>> can find a good common denominator for presentation / view level stuff
>>>> that would be great.I think that's going to need to be a little higher
>>>> level than GEF, but I'd like to avoid deep dependencies on GMF Tooling
>>>> and GMF Runtime if possible, just so that the basic approach will work
>>>> easily with Graphiti and other GEF based tools while still working well
>>>> with existing GMF-based tools. Ideally, the Mylyn tools would plug-in
>>>> without having to specialize the target editors at all. Second best
>>>> would be to provide a really simple extension model for Mylyn-aware editors.
>>>>
>>>> On Jul 14, 2011, at 1:31 AM, Adolfo Sánchez-Barbudo Herrera wrote:
>>>>
>>>>> Miles,
>>>>>
>>>>> I guess you have tried the Ecore Tools to edit ecore models by the
>>>>> means of a diagram-based editor, haven`t you ?
>>>>>
>>>>> It's included in the Eclipse Releases repository, inside the
>>>>> "Modeling" category ( Modeling -> Ecore Tools SDK).
>>>>>
>>>>> Cheers,
>>>>> Adolfo.
>>>>>
>>>>> El 13/07/2011 21:29, Miles Parker escribió:
>>>>>> I'm trying to get a sense for what diagram tools are most used for generic Ecore editing.. I'm one of those luddites who find the Ecore"example" tree editor perfectly usable :) but as we're trying to support the largest community we can with the current Mylyn EMF bridge effort, and I'd like to understand where things are in terms of what is state of the art, what is being supported and pushed forward, etc.. and what if any efforts have been merged, split, etc.. It's of course quite possible that we'll be able to support many or all of the tools, but we want to have a solution that benefits the maximum # of users possible. I'm really only interested in tools used to *edit* Ecore models themselves at this point, though feedback on more generic aspects would be useful as well. In particular is there one underlying technology that should be supported? I realize that these sorts of questions can make people uncomfortable -- none of us like to say"my tool is better than x"
>>> -- s
>>>>>> o
>>>>>> info like"I use x and it works well for.." would be helpful. And while I think Eclipse related discussions should be public as a rule, if you want to share any project information that it wouldn't be helpful to discuss on a public mailing list feel free to email me directly.
>>>>>>
>>>>>> cheers,
>>>>>>
>>>>>> Miles
>>>>>> _______________________________________________
>>>>>> modeling-pmc mailing list
>>>>>> modeling-pmc@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>>>>
>>>>> --
>>>>> <logo.gif>
>>>>> *Adolfo Sánchez-Barbudo Herrera*
>>>>> adolfosbh(at)opencanarias(dot)com
>>>>> <mailto:adolfosbh%28at%29opencanarias%28dot%29com>
>>>>> C/Elías Ramos González, 4, ofc. 304
>>>>> 38001 SANTA CRUZ DE TENERIFE
>>>>> Tel.: +34 922 240231
>>>>>
>>>>> _______________________________________________
>>>>> modeling-pmc mailing list
>>>>> modeling-pmc@xxxxxxxxxxx<mailto:modeling-pmc@xxxxxxxxxxx>
>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>>
>>>>
>>>> _______________________________________________
>>>> modeling-pmc mailing list
>>>> modeling-pmc@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>> ________________________________
>>>
>>>
>>> Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
>>>
>>> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
>>>
>>> _______________________________________________
>>> modeling-pmc mailing list
>>> modeling-pmc@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>> _______________________________________________
>> 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
