Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #458736 +++ Mars nightly build as of 30-Jan-2015 1:19:43 AM. Using attachment 250375 [details] on bug 458736, open the ContainerModel and then expand it to trigger loading of the StereotypeRepairBug model that it imports by ElementImport. From here, the "ModelSetQueryAdapterSizeMatters" EContentAdapter causes all sub-units to load. The result is that: 1. The containment proxy referencing ModelFragment_1 is resolved, which loads that resource. 2. The query-adapter walks that resource and triggers resolution of the proxy referencing ModelFragment_2. 3. That proxy resolution, after loading ModelFragment_2, concludes by attaching that resource's root package to its container in ModelFragment_1. 4. At this point, the UML API's implementation of basic-set-container validates the stereotype applications of the package and its contents. 5. Because at this point the root package of ModelFragment_1 is not yet attached to its parent (remember, we are still actually *loading* ModelFragment_1; resolution of the proxy referencing it has not finished), the profile applications in the root unit StereotypeRepairBug are not reachable from the root package of ModelFragment_2. Therefore, all of the stereotype applications in ModelFragment_2 are invalid and are destroyed. The end result is that no stereotype applications are manifest on any elements in the ModelFragment_2 resource. I give this bug major severity because it can be expected to affect a lot of models imported from RSA, which will not have profile applications applied to every sub-unit individually as is the usual custom for "control mode" in Papyrus. It would not be expected in models created with Papyrus.
Is it something we should fix in the Migration tool (i.e. always apply the profiles from the parent model on fragment resources), or is it another component which is too greedy to remove unknown elements? > Therefore, all of the stereotype applications in ModelFragment_2 are invalid and are destroyed. I think UML itself ignores the unknown applications? And the Stereotype Repair only destroys stereotypes if the user selects this option?
(In reply to Camille Letavernier from comment #1) > Is it something we should fix in the Migration tool (i.e. always apply the > profiles from the parent model on fragment resources), or is it another > component which is too greedy to remove unknown elements? That would avert the problem in this case. But, if users "clean" their models to remove what might appear to be "redundant" profile applications (though IMO they aren't because they support stand-alone editing of sub-units), then the problem will recur. > > Therefore, all of the stereotype applications in ModelFragment_2 are invalid and are destroyed. > > I think UML itself ignores the unknown applications? And the Stereotype > Repair only destroys stereotypes if the user selects this option? No, it isn't Stereotype Repair that's destroying these. It's the UML API, itself, in ElementImpl::eBasicSetContainer(...) when the root package of the element is attached to its containing package from the parent model unit. Stereotype Repair just finds the stereotype instances that had their base_Xyz references cleared by the UML API.
(In reply to Christian W. Damus from comment #2) > (In reply to Camille Letavernier from comment #1) > > Is it something we should fix in the Migration tool (i.e. always apply the > > profiles from the parent model on fragment resources), or is it another > > component which is too greedy to remove unknown elements? > > That would avert the problem in this case. But, if users "clean" their > models to remove what might appear to be "redundant" profile applications > (though IMO they aren't because they support stand-alone editing of > sub-units), then the problem will recur. > I am not fully sure that re-applying the profiles on all fragments/submodels really is the solution. Please remember that in RSA the .efx fragment is not something that you open separately, so the original intention was never to open it standalone, but just to have it in a separate file, e.g. to overcome issues with version control systems which uses a locking scheme when checking out file, e.g. as you normally use ClearCase. So re-applying them will in highly fragmented models will for some kinds of models definitively be a lot of "redundant" profile applications (which I guess will cause lots of "redundant" profile migrations when all these submodels these to have its profile application be migrated). If the migration tool shall re-apply profiles, then I have strong feeling that it needs to be optinal, i.e. a new migration option where you should be able to select whether to re-apply profiles on the submodels or not. Another thing to consider is also that you can have .efx fragment on any level of the model, i.e. not only packages. In the example model I provided where multiple levels of nested packages you can add the additional case where the capsule is also stored into its own separate .efx fragment. In this specific case you can't re-apply the profile in the separate submodel since it has the class (capsule) as its root element. This actually makes the model explorer a bit confused as well and an exception is thrown (which is probably a separate Bugzilla). So as Christian points out, re-applying the profiles is really not a solution. I am not sure if there really needs to be some similar solution as for the .efx fragments, where you have an additional EAnnotation the references the parent .efx fragment .emx model to ensure that you easily can locate the chain of parent fragments/submodels. But that on the other hand, that makes the submodels tightly coupled with its paretn models, which maybe it not what is wanted either.
I should note that the particular steps in comment 0 are critical. Simply opening the StereotypeRepairBug model in an editor will not produce the problem. It must be opened indirectly via expansion of the import in the Container model. It is the sequence initiated by that cross-reference proxy resolution that's the problem.
Any progress/ideas regarding finding a solution to this issue? I am seeing several different kinds of issues related to this when navigating around in large fragmented models imported from RSA and triggering proxy resolution (lazy loading) in different ways. It makes it very hard to understand what is related to this specific issue, and what might be other (possibly unrelated) issues. I can see cases where not only the Stereotype Repair dialog pops up suggesting to delete dangling/destroyed stereotypes, but also in combination with that it is suggested that profiles needs to be migrated (even though they really should not be in need of migration, in this specific case the Documentation and the UML-RT profiles). So apart from stereotype applications being destroyed, it also seem to be some issue with the profile applications that makes the Stereotype Repair wizard want to migrate them. I can also see some additional issues when triggering proxy resolution/lazy loading when validating model, i.e. when you validate the model in a state where only the top level of the model has been resolved/loaded into memory. I assume that validating the model triggers other kinds of proxy resolution/lazy loading scenarios, which combined with this issue causes additional symptoms that are hard to understand.
Created attachment 251357 [details] Example model that initiates profile migration Here is an example model which after import triggers a scenario where profile migration is needed. Steps to reproduce: 1) Import the RSA model 2) Open the imported ModelA. Please note that the first the model is opened in a new workspace it looks like everything is being resolved/loaded into memory. Not sure if this is a bug or a feature, but anway that is an unrelated issue. If this happens then close the model and open it a second time. The second time it will only open the top level of Model A. 3) Now navigate into Model A to reveal CapsuleA. Open CapsuleA to trigger the proxy resolution of it capsule part typed by CapsuleB located in a nested fragment in ModelB. 4) This now triggers the Stereotype Repair dialog to suggest profile migration Not sure if this is just another symptom of the same case as this, or if this is another (but related) issue.
Created attachment 251358 [details] Updated example to initiate both stereotype delete and profile migration I tested a bit more, and made a minor update to the example model to be able to show another scenario, where both stereotype are proposed to be deleted as well as profile to be migrated. Same steps to reproduce as in comment 6, but instead of opening CapsuleA to trigger proxy resolution/lazy loading, open AnotherTopCapsule instead. This triggers another scenario where both stereotype deletion and profile migration is proposed by the Stereotype Repair dialog.
As discussed off-line, one approach to consider to address this problem is introduction of a new kind of controlled unit that is not a semi-independent sub-model but which recognizes a strong dependence on its containing package chain: bug 496299.
This is fixed by the resolution of bug 496299.
Verified in the latest Papyrus-RT build, based on the latest Papyrus Neon build, that the repair dialog no longer pops up, and the attached model opens as expected after import. There is one aspect though, the first time you open the ModelA in the workspace, then a dialog pops up asking if one of the fragment/shard-files of ModelB shall be made writable. This is kind of confusing. As indicated in Bug 461709 Comment 1, this is related to the creation of the .sash-file in the .metadata of the workspace. Once these has been created and you open the ModelA a second time, this dialog does not popup (since not all dependencies are resolved, and ModelB does not get loaded at this point in time). I guess this maybe should be looked into as part of Bug 461709, and not in the scope of this Bugzilla.
(In reply to Peter Cigehn from comment #10) > There is one aspect though, the first time you open the ModelA in the > workspace, then a dialog pops up asking if one of the fragment/shard-files > of ModelB shall be made writable. This is kind of confusing. > > As indicated in Bug 461709 Comment 1, this is related to the creation of the > .sash-file in the .metadata of the workspace. Once these has been created > and you open the ModelA a second time, this dialog does not popup (since not > all dependencies are resolved, and ModelB does not get loaded at this point > in time). I guess this maybe should be looked into as part of Bug 461709, > and not in the scope of this Bugzilla. Now when Bug 461709 had been fixed, I tried this once again. And now the confusing dialog about making one of the fragment/shard-files of ModelB writable when trying to resolve all dependencies when opening the model the first time in a new workspace, does not happen any more. The model opens without dialog, and the lazy loading works as expected according to the steps to reproduce in Comment 6 and Comment 7.
