Community
Participate
Working Groups
This Bugzilla is related to my + CEA comments in Bugzilla 394779, and also related to Bugzilla 394775. A model or a model part in Papyrus consists of 3 files: a .di file, a .notation file and a .uml file. Private/local modelling-time information about which diagram windows that a user happens to have open (which tabs) is stored in the 3-file-model, in the .di file. This means that when a user close a diagram window (tab) or open a new diagram window, and then save, he/she creates a new version of the model. This is not good. (e.g. for collaboration reasons) Such private, modelling-time user information must instead be stored somewhere in the users private/local workspace, not in the model itself. Such private/local info should not even be stored in the Eclipse project. (so my previous comment about the .project file was incorrect)
It seems clearly required for all collaborative work (In general, not necessarily control-mode based collaborative work). However, it is really complicated to achieve. The task is valid, but will probably need deep modifications of the Papyrus model, which means it won't be possible to do until the next version (i.e. Luna, as we're already in API Freeze for Kepler).
Yes - This is also applicable to model containing controlled parts. Any model and part is currently built up as a 3-file-model, and any model/part may contain multiple diagrams. Multiple engineers may work on the same model/part, but preferrably not simultaneously. Any time a user just open or close a diagram in the model or part currently being edited, it gets marks as modified. If it then is saved, and even though only the .di file needs to get updated, all the 3 files are saved and they all get a new timestamp = a "new" version get saved. One way to solve this problem could perhaps be to: 1) Keep individual track of the 3 files and save only the file/-s that needs to be updated with a new content. 2) Move the SashWindowsMngr parts of the .di file to the workspace level, since it only contains information which is individual for each user. (= move it into a new workspace-level file) 3) Automatically save the individual user information into the workspace-level file = not marking the model as modified.
*** Bug 320896 has been marked as a duplicate of this bug. ***
Copied from Bug 320896: > The ".uml" file contains model data, and the ".notation" file contains graphical data, both being shared by all people working on a Papyrus project. > The ".di" file contains more personal data (kind of local settings), such the way windows are displayed, which diagrams are opened, and should typically not be added to a source control. Moreover, this file could be optional and automatically recreated if not present in the project.
Individual user information is typically _not_ stored in the project, like information about the layout of the UI. Instead such information is typically stored at the throw-away-workspace level, in some .metadata/.plugins/xyz catalogue. Also note that the .di file not only contains information about the UI. It also seem to contain metadata about controlled resorces, which seems quite important to store together with other metadata. Example from .di file: <history:ControledResource resourceURL="model.uml"> <children resourceURL="Datatypes.uml"/> <children resourceURL="Classes.uml"/> </history:ControledResource> <history:ControledResource resourceURL="model.notation"> <children resourceURL="Datatypes.notation"/> <children resourceURL="Classes.notation"/> </history:ControledResource>
Actually, the title of bug320896 from July 2010 says it all: Bug 320896 -[Sash Editor] Di file should not be the main file. That bug describes the root of the Papyrus design problem wrt the 3-file-model that builds up a Papyrus model, or a controlled part, while this bug only reports personal user information, which not! should be stored in the same source-controlled model. (= in the same .di file as reported in 320896) This means that Bug 320896 should be reopened and linked to this bug, since that old bug still is very much valid and not a duplicate of this one. Bug 404122 -unable to open model with activity diagram, the reason to why I revisited this bug, should also be reopened, since you can not yet provide a working release showing that "something" has been fixed. (I just got a similar model crash I'm just about to report) That bug should perhaps also be linked to other related bugs. The statement in Bug 320896 that the .di file "could be optional and automatically recreated if not present in the project" is a bit confusing. Simple testing in the latest build Papyrus-Update-N201303250043.zip reveals that the .di file actually is! the top-node / main-node in a Papyrus model. If that file is deleted or renamed to .dixxx the Papyrus model cease to exist. (can be tested/reproduced using a very simple Papyrus project+model) The main .di file is also, often a root cause to crashing models.
*** Bug 421411 has been marked as a duplicate of this bug. ***
Bug 421411 is not a duplicate. It's a different use case.
Fixed in master (Details in Bug 429239) Briefly: The existing *.di files are still used (Legacy mode). They are not used anymore for storing user information in new models. If the *.di file is deleted, and if a *.uml or *.notation file is opened with the Papyrus editor (Through Open with... Papyrus Editor), a new *.di file is created. It will not contain user information.
Great Camille! :) So... The information about which models and diagrams that were open when I close the workspace are now instead stored somewhere in the .metadata catalogue of the workspace, meaning that the next time the workspace is opened the same models and diagrams are opened again?
From what I see the models that are opened is remembered. The diagrams which were active is however not remembered. The first diagram tab is always the active one. Is this ok for you Toni?
The exact view of the open models and their active diagrams when closing the model is what is expected to be shown next time the workspace is launched, including the displayed parts of the diagrams, even the ones not currently active, the zooming etc, just like in other modeling tool I have worked with. This is what users expect. The only time this cannot be expected is when creating a new workspace and importing projects into it.
Bug 430976 opened to track the issues described in Comment 11 and Comment 12 I close this task for clarity
This has been fixed only for newly created models, getting a .di file like: <?xml version="1.0" encoding="UTF-8"?> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"/> ...and a separate entry: .metadata\.plugins\org.eclipse.papyrus.infra.core\<project>\<model>.sash All existing models still suffers from this bug, like the entire NWA product structure, does not get automatically forward-migrated to apply this new approach, still having .di files containing user info like: <?xml version="1.0" encoding="UTF-8"?> <di:SashWindowsMngr xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:di="http://www.eclipse.org/papyrus/0.7.0/sashdi"> <pageList> <availablePage> <emfPageIdentifier href="RadioAccess.notation#_-hM6cWfmEeOBhMx-wLHzcQ"/> </availablePage> </pageList> <sashModel currentSelection="//@sashModel/@windows.0/@children.0"> <windows> <children xsi:type="di:TabFolder"> <children> <emfPageIdentifier href="RadioAccess.notation#_-hM6cWfmEeOBhMx-wLHzcQ"/> </children> </children> </windows> </sashModel> </di:SashWindowsMngr> Existing models must be automatically migrated when opened and the .di files must be cleaned from invalid stuff.
> Existing models must be automatically migrated when opened > and the .di files must be cleaned from invalid stuff. Comment 9 explains the process : > The existing *.di files are still used (Legacy mode). > > They are not used anymore for storing user information in new models. > > If the *.di file is deleted, and if a *.uml or *.notation file is opened with the Papyrus editor (Through Open with... Papyrus Editor), a new *.di file is created. It will not contain user information. For supporting legacy models, this won't be automated. We may add an enhancement request to ask users whether they want to clean a legacy *.di model (Or all such legacy models in their workspace), but this task is fixed
I just tried the process in Comment 9 using the 1.0.0.v201405062026 build: 1) Delete the .di file (having invalid stuff in it, as explained in Comment 14) 2) Open the .notation file using Open With -> Papyrus Editor Core 3) No new .di file is created (= a "clean" one) 4) The .notation file get the Papyrus-logo icon. 5) The opened .notation file get a blank view. = Private/local user info stored in existing .di files remain there forever?
You need some additional steps between 2) and 3): - Make a change - Save A new clean *.di file is created in the workspace > 5) The opened .notation file get a blank view. That's expected: deleting the original *.di file, you lost all information about editor layout (= private user information). So, you're just getting an empty editor. You can open your diagrams from the Model Explorer
Thanks, it worked. Case closed! :)
BTW: This bug and the Bug 430976 opened as a result of this bug is valid also for profile models, I guess ? In any case I think this should be documented under Help to assist all existing users to clean out old / invalid garbage from the .di files in their existing models: the procedure, why it is needed etc. There should be a Papyrus Guide -> User Guide -> Model and Profile Migration Guide covering all sorts of migration issues related to models and profiles, like: 1) Cleaning .di files from old garbage: the reasoning behind the migration = to not have private/local user info is stored in the model, the procedure, why it is needed, where did the information go, etc. 2) Migrating a model to a new version of a profile, and all its steps, the new CDamus windows that pops up, use cases / actions to consider, etc. 3) Migrating a model to a new version of UML. 4) Migrating a model with a proprietary profile applied where both the model and the profile also need to be migrated to a new version of UML. 5) ...and more? NOTE: Feel free anyone to add additional migration issues. I will raise a new bugzilla for this much needed documentation improvement.
Better than documentation would be a menu action in the "Refactor" context menu that converts the *.di resource to the new style (and also one that converts it back). Actually, the documentation is valuable in any case, but I would like to see the actions. I would even volunteer to create them (Camille?)
The new bugzilla spawned from this one is Bug 434361.
