Community
Participate
Working Groups
With the implementation of a controlled unit flavour that is not editable independently of its parent unit in bug 496299, some new UI is in order to let users determine which flavour a controlled unit should have: "classic" or the new "dependent" unit. (internally, these controlled units are dubbed "shards", but I'm not sure that this is the best terminology to face the user. Ideas for a branding name are welcome) This new UI should provide: * an option on creation of a controlled unit to implement either classic or shard mode. This is always remembered for the next invocation of the control action * an action to change a controlled unit from classic to shard mode and vice versa * a decorator on the ibis-head icon for controlled units in the Project Explorer. This would be new for the "classic" mode units, too. This would be driven by the new index, which tracks all cross-resource containments and also distinguishes those that are shards from the classic mode. so potentially these flavours could have different decorations
A link to a design page on the wiki: https://wiki.eclipse.org/Papyrus/Neon.1_Work_Description/Improvements/Control-Mode
New Gerrit change created: https://git.eclipse.org/r/77939
Gerrit change https://git.eclipse.org/r/77939 was merged to [streams/2.0-maintenance]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=9073a527c12f1be30333e7e0d6b3d490ba751a36
New Gerrit change created: https://git.eclipse.org/r/79573
Gerrit change https://git.eclipse.org/r/79573 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=ae293862c718921e47a62e456d48f3c19cfbe78e
(In reply to Eclipse Genie from comment #3) > Gerrit change https://git.eclipse.org/r/77939 was merged to > [streams/2.0-maintenance]. (In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/79573 was merged to [master].
I've tested this in the context of the latest Papyrus-RT build, based on the latest Papyrus Neon build and it looks good. First I was expecting the "shards" to be more different, but maybe it is best to stick with the "submodel"-terminology and only differentiate if its "independent" or not. One thing that I noted though was that when you created a new submodel, both an indepent and dependent submodel, there is an additional .sash-file created. Is that really intentional, that the submodel should have their .sash-file (then possibly stored in a version control system)? When reintegrating a submodel, then the .sash-file is left, so I guess there is something not working as expected when it comes to this .sash-file being created for a submodel.
(In reply to Peter Cigehn from comment #7) > > One thing that I noted though was that when you created a new submodel, both > an indepent and dependent submodel, there is an additional .sash-file > created. Is that really intentional, that the submodel should have their > .sash-file (then possibly stored in a version control system)? I didn't intend to change anything in the management of .sash resources, and I don't think anything would have changed unintentionally. I thought it best that, as the Project Explorer requires the *.di resource, the corresponding workspace-private *.sash should also be maintained because it will be assumed by various code to exist, even if it isn't used (it is only used by a sub-model that can be opened). And a sub-model can change modes (if it's a package) so there is usually a possibility of the *.sash being used. > When reintegrating a submodel, then the .sash-file is left, so I guess there > is something not working as expected when it comes to this .sash-file being > created for a submodel. This is a more general problem: the *.sash resource is never deleted from the workspace metadata area when a model is deleted. cf. bug 440443
I think that we possibly are talking about different things. Normally the .sash-file is always located in the .metadata folder of the workspace, right? But what I am talking about is that you now get a .sash-file located in the same location as the .di/.notation/.uml-files, and it gets grouped by the "one file". And when reintegrating the submodel, the .sash-file is left visible in your project (if it is left in the .metadata folder then I would not have seen this). Is that what you mean also? Or are you referring to the fact that the .sash-file now should get located directly in your project (which will cause it to be stored in your version control system and shared with other users, which was one of the driving forces of placing the .sash-file in the .metadata-folder)?
Also when you import a fragmented legacy model, the (dependent) submodels that you get do no get the .sash-file created at the same location as the .di/.notation/.uml-files, i.e. if you file the "one file" node open you do not see a sash-node below as you do for the case when you create a submodel using the menu choice "Create submodel". So there is some difference in the location of the .sash-file also for the case of importing a fragmented legacy model vs. creating new submodels via the UI.
(In reply to Peter Cigehn from comment #9) > I think that we possibly are talking about different things. Normally the > .sash-file is always located in the .metadata folder of the workspace, right? Right. > But what I am talking about is that you now get a .sash-file located in the > same location as the .di/.notation/.uml-files, and it gets grouped by the > "one file". And when reintegrating the submodel, the .sash-file is left > visible in your project (if it is left in the .metadata folder then I would > not have seen this). Oh, I hadn't seen this during development of this feature, but now I do. I shall check to see whether this is a new problem caused by this feature (nothing is changed in the management of *.sash resources, AFAIK).
(In reply to Christian W. Damus from comment #11) > > Oh, I hadn't seen this during development of this feature, but now I do. I > shall check to see whether this is a new problem caused by this feature > (nothing is changed in the management of *.sash resources, AFAIK). Indeed, this is caused by a flaw in the fix for bug 461709.
I've tested this again, now when Bug 461709 is fixed again, and now it works without getting the .sash-file at the same location as the .di/.notation/.uml-files. When re-integrating a submodel you do not get at .sash-file hanging around in your project anymore. I think that this looks good, and we can keep the existing terminology regarding submodel with the only distinction if they are independent or not. I put this one into verified.