Community
Participate
Working Groups
Created attachment 265996 [details] demonstration model and documentation of issue This issue could involve interaction between Papyrus Core, Interactive OCL Console, and /or the RSA Import feature. In a large model imported from RSA, otherwise correct allOwnedElements() OCL queries fail if any package contains an offending BadEnumerations Package in its subtree. See the attached .zip file with a Papyrus model project with model stripped down to the minimal model that exhibits the symptoms. There is also a document (docx and pdf) showing the exact OCL query, sequence of user actions, and OCL query NPE and UnsupportedOperationException output. The doc also includes details of the Papyrus installation. I've spent over a day trying to diagnose by experiment, since I haven't yet set up a developer / debug config. Since workflow is requiring regular migration from RSA with large packages containing Enumerations like this, a manual workaround of recreating the packages within Papyrus isn't feasible. Thanks!
Confirmed issue per attached model and documentation for the latest Papyrus 2.0.1 distro for Mac 64bit. Also, note that either the NPE issue or the UnsupportedOperationException issue are now showing up for all three packages of enumerations: BadEnumerations, GoodEnumerations, and Save, in the attached sample model.
Issue appears to be related to how profiles are imported. If the RSA .epx files are not removed from the project directory when the main model .emx file is imported, the RSA import will default to using the .epx files rather than the newly imported Papyrus profile.uml files. We added a step to the work flow to remove the .epx files from the project directory after import and that seems to have resolved the problem.
(In reply to Jim Albers from comment #2) > Issue appears to be related to how profiles are imported. If the RSA .epx > files are not removed from the project directory when the main model .emx > file is imported, the RSA import will default to using the .epx files rather > than the newly imported Papyrus profile.uml files. We added a step to the > work flow to remove the .epx files from the project directory after import > and that seems to have resolved the problem. Yes, I can also just confirm that the original .epx file needs to be removed from the workspace after importing a profile into Papyrus format. Otherwise, as you have concluded, there will be issues when importing .emx models which have this profile applied, since references to the original .epx file will be possible to be resolved during import and the profile switch to the profile on Papyrus format will not work as expected. See for example my comments related to this aspect in Bug 505330 Comment 5.
We have a workaround visible to those can find this issue in bugzilla. For the OCL Pivot / Xtext Console team and the RSA import team, there appear to be a couple of opportunities to make both plugins more robust. Not sure best way to bump this onto the respective radars.
