Community
Participate
Working Groups
Created attachment 231215 [details] Slides with clarifying details. See attached slides for info. It is up to the user to ensure that the version of the local and registered profiles are the same, but Papyrus should warn if they are different. This should be supported early and as the initial part of supporting the MigrateReq - 1, -2, -4 and -5 requirements. This one is related to Bug 408316.
Currently, the migration from the previous version of a Profile to the current version is done automatically by a generic transformation in Eclipse UML2. This transformation can be automated, because each uml::Stereotype is unique (via an Identifier) within a Profile, and all Ecore Definitions have a reference to this unique uml::Stereotype. This means that, if a uml::Stereotype is renamed between version 0.1 and 0.2, it keeps the same identifier, and the transformation knows how to convert older Ecore versions of this stereotype to the new version. If we have several physical versions of the same Profile (e.g. the registered one and the local one), we cannot guarantee the traceability between each physical versions (i.e. if the same Stereotype is created in both models, they will still be considered as two different Stereotypes, and cannot be transformed to each other). This might work however for simple workflows (Work on a local version of a profile -> deploy it "as is" in a plug-in without changing anything -> transform from one to another), but users will need to be careful. Note that EMF Compare retains identifiers, so merged profiles should still be properly converted (Add a new Stereotype in local profile > Compare with the plug-in profile > Merge the stereotype > Re-deploy the plug-in)
This is about both MigrateReq1 and MigrateReq2. This is also about arbitrary & proprietary DSL profiles and models using them. This is _not_ about migrating to a new version of a profile. This is about migrating a bunch of DSL models to Papyrus. 1) An arbitrary model is exported along with its applied DSL profile/-s. 2) Plugin/-s are created for "registering" the DSL profile/-s for Papyrus using the profile-files exported in 1) above. 3) For every such user model imported in Papyrus, where the profiles get imported as local profiles, users need to switch to the registered versions. The "real" switching is as simple as described in the attached slides. The local profile-file and the registered ditto have exactly the same content. (= they are the same profiles having exactly the same stereotypes) This profile switch should be supported via menu discussed in Bug 408316, where a menu example can be found in the slides above. This export, import and switch of models+DSL profiles has been tested and proven to work just fine. Advanced users like DSL developers may also need the flexibility to easily switch from a registered profile to the same but local version of the profile for arbitrary & advanced experiments. The advanced users know what they do and are always careful. Merging local and registered profiles is a different and separate use case.
Sorry - Correction: This is about both MigrateReq1 and MigrateReq4. (1 and 4)
Initial contribution in 3cc162683178bf83ab9bc5e73475ab3415eb09e5 Pushed to master - Provide a new generic API to edit links between EMF Resources, through their URI - Specialize the behavior for switch profile versions (Local -> Local copy, Local -> Registered or Registered -> Local) There is currently no security, i.e. it is currently possible to switch between two unrelated profiles (Resulting in model with invalid profiles/stereotypes, which can still be manipulated) The tool supports switch from different versions of the same profile (e.g. switch from Local v1 to Registered v1.1).
Is this "initial contribution" available in Papyrus-Update-N201308190044 and, if so, how can it be tested? An advanced user switching between local <-> registered profiles knows what he/she is doing when making this switch. :)
Right click on a UML File in the project explorer > Refactor > Switch profile applications. I've noticed right before my vacation that it only "seems" to work for Stereotypes, but tests reveal that there are some issues. The profile application is correctly switched, but instances of Stereotypes are not. However, there seem to be some conflicts in the UML file serialization which sometimes make it work (The source and target profiles have the same XMI ID and NS URI, which leads to these serialization conflicts). So, do not expect too much from this "initial contribution". By the way, the menu is currently located in the project explorer because it works on a new in-memory version of the model. I could add the action to the profile tab or model explorer, but we'd most likely still need to restart the editor afterwards.
Created attachment 234961 [details] Screenshot showing no "refactor" menu option I have two projects containing the same very simple class model having applied stereotypes on them. In one project the model has an applied local profile. In the other project the model has an applied "registered" runtime profile. The local and runtime XYZProfile.profile.uml files are identical, meaning that switching between the two should be absolutely fail safe. When right-clicking on the uml file in project explorer there is no refactor menu available in Papyrus-Update-N201308190044.
Created attachment 234964 [details] Screenshot Local vs Runtime profile Attached is a screenshow showing the profile properties for these two simple models, and the location of the profiles, as fixed in Bug 408316. Switching between profiles is most naturally handled via the Properties view, (preferrably in a simple and user friendly way as illustrated in the slide) where you can apply a local profile, a runtime profile or switch between them.
I forgot to include the UI plug-in to the build. It is fixed in bbed572a66415839c48ba43e17376f21245f4d35 (Pushed to master) > The local and runtime XYZProfile.profile.uml files are identical, > meaning that switching between the two should be absolutely fail safe. Be careful when you test: Papyrus will look like it worked, but you may actually have Stereotype Applications from Profile A and Profile Application from Profile B (Or maybe not, as there is some serialization conflicts; there's an undeterministic behavior here). You can easily end up with false-positive (The model seems to be OK but is not)
Created attachment 235028 [details] Switch Local to Runtime profile almost works - One thing missing Just installed the Nightly Build 2008-08-29 and then I found the switch menu. 1) Having the switch menu located as in this example is quite weird. Instead there should be an additional "Switch Profile" button located in the Properties.Profile Window for the model. (more natural location) 2) When clicking on this buttn there should be an "Are You Sure" type of dialogue window popping up before continuing. 3) When switching the profile there should be a confirmation in the switch window that the profile has been switched when clicking on "Apply". Right now you have to look in the Properties.Profile window to get this confirmation, but only after the switch has been made. 4) In this window the pop-up helpinfo is missing for the profile buttons. 5) When doing the switch the model gets autosaved. There is no indication in the model diagram tab that it hae been modified and needs saving. 6) When doing a switch from a local profile to a runtime profile in my simple example the switch seems to work. The stereotypes are still applied to the classes both in the diagram and in the Model Explorer, and the single tagged value (stereotype attribute) I have still had its value assigned. :) 7) When making a windiff of the before-and-after .uml files I see the same switching of the profile as in the attached slides above. But there is one thing missing... (to be continued)
Created attachment 235029 [details] The Missing Profile Thing To Switch... If you check the attached slides you will find a profile switch in 3 different places of the .uml file. In the switch from a local to a runtime profile I just did the first one is missing. On line 2 in this windiff screenshot there is still a reference to the local profile, while the other two are referring to the runtime profile. Perhaps that's why you sometimes get errors, as you mentioned in Comment 6 and Comment 9. Could that be your problem? In my test the stereotypes and tagged value are still applied/assigned to my classes also after I close the model and opening it again. I will also try out switching from a runtime profile to a local profile. If this all works fine, and you locate & correct the bugs you found, it means that we can export a model with its applied profiles in one tool and then import it into papyrus and switch to the runtime versions of profiles.
I just verified this "missing thing" to switch described above. If you switch between two identical local profiles located in two different projects, and then delete the project containing the profile you switched from, the stereotypes in your model will crash.
Our internal story on this is now closed, so I'd appreciate this UI menu and switching problem to be adressed a.s.a.p.
I have now updated our internal backlog for this one, now stating: Partly fixed 2013-08-30. Still one profile ref remaining to switch. Not switching this one, the stereotypes in the model will crash.
Target Milestone for this one says SR1. Did it make it into SR1? Also see Comment 10, Comment 11 and Comment 12.
I have now got two questions from different directions asking for the status of this bug. Has the last profile-ref-thing been fixed in SR1 ? This capability of being able to import proprietary models+profiles into Papyrus is an important milestone I like to be able to report to our internal stakeholders, and with no remaining bugs to fix.
(In reply to Toni Siljamäki from comment #11) > > On line 2 in this windiff screenshot there is still a reference to > the local profile, while the other two are referring to the runtime profile. > > Perhaps that's why you sometimes get errors, as you mentioned in > Comment 6 and Comment 9. Could that be your problem? Yes, that's the reference to the profile schema that EMF understands, to create stereotype applications using the correct Ecore definition. I'll take over to complete the profile switch, addressing the stereotype applications problem.
Great! Would be nice if the switching-menu was available under Properties->Profile. Right now it is "hidden" under Project Explorer -> myModel -> Refactor.
Fixed on git master. **NOTE** that, in order to use this feature, it is necessary to update to the latest UML2 integration build. Commit 4d809b5: Reworks the UI, including moving the "Refactor -> Switch Profiles..." action into the Model Explorer. See a demonstration here: http://youtu.be/I4OhEqDG7P8 Commit 9f64bea: Rationalizes the implementation of the stereotype application reconstruction on the latest UML2 API. This eliminates the need to copy code from the overridden UML2 API. Commit 1ef51f2: Updates the build RMaps to pick up the latest UML2 integration build, which has improvements in the extensibility of the (internal) StereotypeApplicationCopier API. Commit ac32608: Basic implementation of stereotype application reconstruction as a pluggable participant in the dependency-update operation. Includes reinstated and new JUnit test cases for various scenarios, including switches to compatible and incompatible profiles and handling of changes in required metaclass extensions.
Sorry, but profile switching does not work properly. It's the original problem where line 2 in the .uml file does not get updated, but in this case for a different profile / DSL and for a different model. It may have something to do with Bug 432737 - Profile Update Not Working, a bug which still is in state UNCONFIRMED.
Created attachment 242152 [details] workspace_NWADSL_demo5_Luna_showcaseModelsWithLocalPofile_testSwitch_notWorking.zip Attached is a workspace for a stripped test case showing the problem. It has 2 exported projects in it, plus a couple of jpegs. Focus on the Direction project. It has a model in it unsuccessfully migrated to an updated version of the profile, as described in Bug 432737. But this is not the problem here, described by this update of this bug. In the Direction project: * NWAProfile_version_0.4.1_local contains the model having the local profile applied to it. * NWAProfile_version_0.4.1_plugin contains the model after the profile have been switched to the deployed plugin profile. (same model as in the Direction folder) When the model is opened in Papyrus and when checking the version of the applied profile in the Properties view is says that version 0.4.1 is applied, which is not really true, just as described in Bug 432737. The problem here is that this "switch" from a local profile to the same plugin profile with no warning that there is something seriously wrong with the profile (on line 2 in the .uml file) we are switching from! The problem with the model for which we are switching the profile is that it has not been properly upgraded to the latest version of the profile (see Bug 432737), and the problem here is that this switch takes place without noticing the fact that the model refers to two different versions of the same profile. The bug described by Bug 432737 should be detected before trying to switch profile.
(In reply to Toni Siljamäki from comment #20) > Sorry, but profile switching does not work properly. > > It's the original problem where line 2 in the .uml file does not get updated, > but in this case for a different profile / DSL and for a different model. (In reply to Toni Siljamäki from comment #21) > > The problem here is that this "switch" from a local profile to the same > plugin profile with no warning that there is something seriously wrong with > the profile (on line 2 in the .uml file) we are switching from! I don't know that this is a reason to re-open this bugzilla. The profile switch feature is not intended to fix this kind of problem: that's what the stereotype repair function in bug 431953 is for, which is still in code review. The fix for 431953, when it is merged, will kick in automatically to detect the malformed profile application when the model is opened. The user can then fix it before ever attempting a profile switch.
Created attachment 242179 [details] Switch Profile Not Working - Additional Info The attached zip with projects also contained a couple of jpgs. Here is another jpg with some additional info. Maybe the bug 431953 solution is capable of handling also this problem, even though it was created for a completely different problem (zombies). Here the problem is multiple "applied" versions of the same profile. The example model is the simplest possible: A single applied stereotype. The DSL profile is deliberately kept as simple as possible. The problematic Direction model has two simultaneously "applied" versions of this profile, version 0.3.3 and version 0.4.1, and both versions exists in the NWAProfile.profile.uml file, both in the loval variant of the profile and in the plugin variant of the profile. The simple applied stereotype is unchanged between the 0.3.3 and 0.4.1 version. In earlier emails/bugzillas I described how models crashed when removing older versions than the latest one applied to them, which indicates that these models probably also had multiple versions of the same profile applied. The problem described by this Direction-model-test-case is that when switching to the plugin variant of the 0.4.1 profile version, it still has the local 0.3.3 version of the profile applied to it. As you can see in the latest jpg attached it seems that the profile switching software ignores the applied stereotype instance in example 1) = not touched. In example 2) I'm using a version of the Direction model in which I manually hacked out the local 0.3.3 version and replaced it with the 0.4.1 version. When switching example 2) to the plugin version, the profile switching software also touches the applied stereotype instance, and also makes a switch to the plugin variant of the profile version 0.4.1 on line 2 in the .uml file.
(In reply to comment #23) > > The example model is the simplest possible: A single applied stereotype. > The DSL profile is deliberately kept as simple as possible. > The problematic Direction model has two simultaneously "applied" versions > of this profile, version 0.3.3 and version 0.4.1, and both versions > exists in the NWAProfile.profile.uml file, both in the loval variant > of the profile and in the plugin variant of the profile. Not exactly two profile versions applied: one profile version is applied, but stereotype applications are instantiated from a different version that is not applied. Anyways, this is one of the cases that the new repair feature of bug 431953 will catch and fix. So, attempting a profile switch on it will be expected to have incongruous (if not unpredictable) results. > As you can see in the latest jpg attached it seems that the profile switching > software ignores the applied stereotype instance in example 1) = not touched. Right, because it is an instance of stereotype from a different profile (version) than the profile (version) that we are switching. > In example 2) I'm using a version of the Direction model in which I manually > hacked out the local 0.3.3 version and replaced it with the 0.4.1 version. > When switching example 2) to the plugin version, the profile switching > software also touches the applied stereotype instance, and also makes a switch > to the plugin variant of the profile version 0.4.1 on line 2 in the .uml file. Actually, as of the latest nightly builds, you should no longer see the XMI IDs of stereotype applications changed by the profile-switch function. That was an oversight that is now corrected, to minimize the possibility of breaking external HREFs to these objects from other resources (especially diagrams) that aren't loaded at the time of switching profiles.
Now that the fix for bug 431953 has been pushed, I can work on integrating that with the profile switch function such that profile switch will be conditional on a the stereotype repair not finding any problems.
Commit 307a6a64: Integration of the Stereotype Repair function as a precondition for Profile Switch. A new extension point provides for pluggable profile-switch precondition checks. An extension is implemented that runs the Stereotype Repair on all currently loaded resources (of the model being edited, not libraries), triggering the same dialog that is launched on model open if there are any broken stereotypes found. Depending on the outcome of Stereotype Repair: * if there were no problems to fix, then the Switch Profiles dialog is presented immediately * otherwise, the Stereotype Repair dialog is shown first to let the user fix broken stereotype applications. When this dialog is completed, * if any stereotype problems remain, the user is warned that Profile Switch may not be able to complete normally and is asked to confirm (default option is to abandon the profile switch). If the user opts to proceed, the Switch Profiles dialog is presented * if all stereotype problems were cleared up, the Switch Profiles dialog is then presented We may find additional precondition checks for profile switch. If so, the extension point is ready to incorporate them. Any precondition that returns an error status abandons the profile switch procedure. So, this should cover the remaining profile switch error use cases.
I just tested switching from local to plugin profile in the attached example. When opening the model with the local profile in it, it first get "cleaned" from this having-multiple-profile-versions problem. Then the switching to the plugin profile works perfect, with the profile application xmiid's untouched. This works perfect. Great job!
