Bugzilla – Full Text Bug Listing
| Summary: | [Model Import] Profile/Stereotype assignments lost after importing models | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Ronan Bar <ronan.barrett> |
| Component: | Others | Assignee: | Project Inbox <mdt-papyrus-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cletavernier, papyrus-bugs, patrik |
| Version: | 1.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | dx deploy minor import | ||
| Bug Depends on: | 408491 | ||
| Bug Blocks: | |||
|
Description
Ronan Bar
Actually just thinking about this some more. I see at least 2 options to make this work. 1) We get profile in plugin providers to change their Pathmaps to use the .uml extension but maintain the old unique identifier after the #_ in the URI. They would need to support this naming convention if they want the importer to work 100%. As with all naming conventions this is liable to fail at some point. 2) Look up the EMF Registry and find a match for the UML Profile's NS URI. If a match is found then alter the link (pathmap in the model element and also the profileApplication tag) in the model to the profile in Papyrus. Hi Ronan, See Bug 408491, which proposes a solution for this issue. It is only partially implemented, however. Fixing Bug 408491 should be sufficient to fix also this bug. The use cases in this bug and Bug 408491 are a bit different. In Bug 408491 we assume that we have a model with some arbitrary, proprietary profiles applied in the "other tool", where we: 1) Export the model + profiles in the other tool (semantic models) 2) Create Papyrus plugins for the profiles 3) Create new model in Papyrus based on the exported model (with local profiles) 4) Switch from the locally stored profiles to the plugin versions Bug 408491 is also about switching from a proprietary plugin profile to a locally stored version for advanced users. In Ronans use case the new import model+diagram feature was used, I guess, created to automatically switch to the Papyrus variant of the ROOM profile. When importing a model having arbitrary profiles applied, we must assume that the user already have created Papyrus versions of these profiles. When such an arbitrary profile is detected during model import, the import function could perhaps popup a window asking the user to pick the Papyrus version of it. Also see: Bug 418542 -Remove unused profile from migrated model = crash, applied stereotypes gone. (In reply to Toni Siljamäki from comment #3) Yes Toni the use-case is a little different. As you say the profiles are never local in either tool i.e. not in a workspace but in a plugin. So I expect a different workflow, as follows: 1) Open Papyrus and select the model to import in the Project Explorer 2) Select the Model Import feature I don't expect the user to do any more than this. As long as there is a UML profile with compatible stereotypes and IDs Papyrus should switch the model to use this profile instead. This is a common use-case for using 3PP based tools which use profiles in plugins. I assume the 3PP plugin provider has already migrated the profile to papyrus and the user has installed the 3PP plugins. (In reply to Ronan B from comment #5) What I'm most concerned about is when things go wrong, due to: 1) User mistakes. 2) Papyrus bugs. 3) Combination of the above, perhaps due to a missing use/test cases. Our primary concern is to import models from this "other tool", and we expect the switching to the Papyrus ROOM profile to be as automatic as possible when importing models, since this is the main profile for the majority of our models. 4) The simple model use case is when this is the _only_ profile. Importing such a model should be fully automatic. 5) A bit more complex use case is when a model also applies some other vendor-/tool specific profiles in that "other tool", which we may not need in Papyrus. 6) A more complex use case is when a model in that "other tool" also applies an arbitrary number of proprietary profiles, which can be related to a certain DSL, or perhaps deployment specific profiles, such as marking models. If the sun is shining and we have created Papyrus versions of all needed profiles, and the user also have them installed in the version of the Eclipse environment the user is currently running, then the model import should be very-automatic wrt switching to Papyrus profiles. Then we have the cases when Papyrus versions of profiles to automatically switch to, during model import, cannot be found, for any reason, and the cases where vendor-/tool specific profiles are not needed in Papyrus. In these cases the model import feature should popup a menu allowing the user to make some clever choices wrt the profiles that cannot be found. (= prevent importing crashing models, causing lots of lead time) The idea here is to force the user to make an active choice in cases where a plugin version of the profile cannot be found. In this case, and in order to continue the import, the user _must_ pick a local version of the profile. The user can then create a plugin version of the profile and switch to it at some later point in time. (or install already existing plugin versions) Wrt to the vendor-/tool specific profiles which are not needed in Papyrus, these could perhaps be discarded automatically by Papyrus, but I'm not sure if this a good idea or not. I don't know all of them, which are used by models across the ///-planet and for what they are used. Here are a few examples from one exported model: Default.profile.uml is vendor specific and contains misc stuff. It was applied by the exported model, but not used by it. It could be safely discarded. Deployment.profile.uml, same here, applied but not used. Contain only stereotypes with shapes. InteractionProfile.profile.uml, same here, applied but not used. Vendor specific, perhaps vendor DSL specific. ProfileBase.profile.uml, same here, applied but not used. Have something to do with images. ...and there are several more. "The idea here is to force the user to make an active choice in cases where a plugin version of the profile cannot be found. In this case, and in order to continue the import, the user _must_ pick a local version of the profile." I'd like to take it a bit further even and have an option to create a local profile file of none exists. It is already planed to have a specific support for the UML-RT Profile, because it is an actual conversion. So we should distinguish two cases: 1) Migrate a source model profiled with a tool-specific profile, to a papyrus model with an equivalent papyrus-specific profile (e.g. ROOM to RT, Default to "Something", etc). This can and must be automated, as it is limited to a clearly identified subset of well-known profiles 2) Migrate a source model profiled with arbitrary user-defined profile, to a Papyrus model with the exact same migrated profile. In this case, the idea was to migrate the profile and model separately, then use the "Switch profile" feature. In the later case, it is probably not a good idea to migrate the profile along with the model, because if we migrate N models, we only want to migrate the profile once. Moreover, it is up to the user to decide whether the profile should be local or embedded into a plug-in. The "Switch profile" tool in Bug 408491 has been done just for this case. In case 1), the Papyrus migration tool needs to take care of the migration. It is not yet available for the UML-RT profile. Note that this choice does not need to be made at the migration time, because even if there is no equivalent profile available during the migration, all the information remains in the serialized uml file. It is not "visible" in Papyrus, but it is not "lost". If, at some point, later, you decide that you want to retrieve this information, you can import the related profile and use the "Switch profile" action. All information will be retrieved. This assumes, of course, that the "Switch profile" action works properly, which is not yet the case, as specified in Bug 408491. Hi, Just to clarify I was not talking about the RT profile. I was talking about another 3PP plugin/profile. The approach should be generic for this use-case I think. (In reply to Camille Letavernier from comment #8) OK, I will refine my statement: What I'm most concerned about is when things go wrong, due to: 1) User mistakes. 2) Papyrus bugs. 3) Combination of the above, perhaps due to a missing use/test cases. ... The idea here is to force the user to make an active choice in cases where a plugin version of the profile cannot be found. In this case, and in order to continue the import, the user _MUST_ either pick a local version of the profile _OR_ click on a "discard" button, meaning "I know what I'm doing, and I will ensure that the missing profile exists and is properly applied to this model before I try to use this model in Papyrus or report any errors". We don't want 500 engineers across the planet to start migrating models leading to crashing models all over the place and hundreds of error reports just because we could not assign a migration-police-officer to supervise the migration of each and every model. If a needed profile does not exist the user must be informed so during the mogration process (during the import) to allow him/her to make an active choice on how to proceed, or ask some to help him/her out. Current status: - Profile switch can be applied manually after migration (Bug 408491) - UI / Usability can still be improved (As described in Comment 3, Comment 6, Comment 10) I reduce the severity to normal Further usability improvements (To automate the Profile/Library reconnection) are tracked in Bug 446574. All other bugs mentioned in this task are fixed I close this task Using new import wizard so workflow is better. |