Community
Participate
Working Groups
I am unsure about the correct terminology therefore i will describe what i did: I followed the getting started tutorial (http://wiki.eclipse.org/Intent/Getting_Started) and defined the concepts of the metamodel (like Database, DBSchema, DBTable, etcetera) as described. After the quick fix these were added to the metamodel (as expected). Then i removed "Database" definition from the Intent document which resulted in a synchronization warning ("The EClass Database is defined in the Working Copy model but not in the Current Document model.") I wanted to use the Compare Editor to add the EClass Database again to the Intent Document but in the Compare Editor it is only possible to copy from left to right (from Intent Document to Working Copy). I don't know if this behaviour is as designed but i expect to be able to decide whether i copy from left to right or from right to left.
You're absolutely right. Merging changes from left (the document) to right (the model) already works as it is a basic application of EMFCompare. Merging changes from right (the model) to left (the document) is less straightforward, and some important choices have to be made : let's take your example. In your intent document, the EClass Database is not defined but it is in the model. When you merge changes from right to left, what do you expect Intent to do : (1) Add the Database definition inside the EPackage which contains it (2) Add the Database definition inside a new modeling unit that contribute to this EPackage Both solutions are not satisfying : (1) forces you to document your EClass at the same place as the EPackage (which is exactly what we do not want to do with Intent) and in (2) we don't know where to create the new modeling unit. What I propose is that each intent document contains a "special" hidden chapter called "Non document elements", that you cannot see in the arborescence and cannot edit manually. This chapter will contain all modeling units created automatically when merging changes from model to document (solution (2)). So when you merge changes from model to document, you will not have synchronization issues any more as the model is defined in your documentation, but you'll get "non documented" warnings as no documentation is associated to these elements. A new view called "Non document Element" would list all elements that are defined in this chapter. With a simple drag and drop from this view inside an intent editor, a new modeling unit describing only the element you've dropped (whether it's the Database EClass or only one of its attributes) will be created. I think this mechanism has 2 main benefits compared to (1) or (2) : - when merging changes from model to documentation, you are totally free to choose where the merged elements should be documented (inside an existing section ? inside a new section ?). - when merging changes from model to documentation, you are totally free to document only sub-parts of the model and not the entire models. One can imagine that the "non documented" warnings could be customized : for instance you can say "an EClass should always be documented, but not an EAttribute". Which would mean that if you have an EClass in the "non documented elements" view you'll get a warning, but not if you have only EAttributes. This could be great for retro-documenting existing models or projets : you first make a big merge from workspace to documentation, that would create all the modeling units inside the "non document chapter". Then you fix the "non documented" warnings step by step, creating the documentation. What do you think about this solution ?
It is now clear to me that automatically merging from right to left makes little sense. What you propose seems a nice solution to me. In addition to the "Non document element" view you could also offer the option in the content assist to "Add a non-documented element".
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
