Bugzilla – Full Text Bug Listing
| Summary: | [Tooling] Decide whether UML-RT architecture context shall be default context in Papyrus-RT 1.0 or not | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus-rt | Reporter: | Peter Cigehn <peter.cigehn> |
| Component: | General | Assignee: | Christian Damus <give.a.damus> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | charles, planger, sredding |
| Version: | 1.0.0 | ||
| Target Milestone: | 1.0.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=516138 https://git.eclipse.org/r/99906 https://git.eclipse.org/r/99907 https://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=277d045ee06ca40fca0fb4149b6f30c59ed2fb0b https://git.eclipse.org/c/www.eclipse.org/papyrus-rt.git/commit/?id=8ff6cd1873d201f4fe26ba86eac8ed14873db6d4 |
||
| Whiteboard: | depends_on_papyrus | ||
| Bug Depends on: | 518789 | ||
| Bug Blocks: | 518447 | ||
|
Description
Peter Cigehn
The end-user setup can be updated even before the Oxygen release because the unrecognized preference key is completely harmless. New Gerrit change created: https://git.eclipse.org/r/99906 New Gerrit change created: https://git.eclipse.org/r/99907 Oddly, it seems that the initialization of the Papyrus Architecture context preferences in the plugin_customization.ini doesn't seem to have any effect. The default in a new installation with a new workspace is always UML. I need to investigate whether there's a bug in Papyrus, that somehow it is not initializing its preferences correctly. (In reply to Christian W. Damus from comment #4) > Oddly, it seems that the initialization of the Papyrus Architecture context > preferences in the plugin_customization.ini doesn't seem to have any effect. > The default in a new installation with a new workspace is always UML. > > I need to investigate whether there's a bug in Papyrus, that somehow it is > not initializing its preferences correctly. If I remember correctly, there were similar issues with some of the properties for EMF Compare. Maybe Philip can give a hint about what the issue was with the EMF Compare preferences and how it was solved. The problem in EMF Compare was that the preference values were not read from the configuration scope, if there was no preference value in the instance scope. The configuration scope holds the pre-configured values specified in the plugin_cusotmization.ini. If there is no user-specific setting, the instance scope holds no value. Therefore, the preference values have to be read so that we fall-back to the next higher scope (instance -> configuration -> default). To do that in EMF Compare, we switched to using the platform's IPreferencesService or -- if we were in a UI context -- the IPreferenceStore. See also https://git.eclipse.org/r/#/c/78313/ and https://git.eclipse.org/r/#/c/81970/ where this change has been implemented. Yes, that is exactly the problem. The ArchitectureDomainPreferences class only looks at the instance scope. I'll raise a bug for Papyrus, but in the mean-time, I'm not sure what we can do to work aroud this in 1.0. (In reply to Christian W. Damus from comment #7) > Yes, that is exactly the problem. The ArchitectureDomainPreferences class > only looks at the instance scope. > I'll raise a bug for Papyrus, but in the mean-time, I'm not sure what we can > do to work aroud this in 1.0. I guess we have to live with the the default context when the RCP is not UML-RT. And that we only see it for Papyrus-RT Installer based intallation (where we do know that it works, I guess due to that the preference task in Oomph sets the preference for the instance scope, i.e. for the workspace). I guess we can still set the preference in the RCP to prepare for a fix coming in base Papyrus (tracked by this bug). Not sure if we need a separate tracking bug on the Papyrus-RT side or not, tracking the bug in Papyrus, since it will hopefully "just work" when the fix comes in Papyrus. But maybe it is good to track when that happens, e.g. for inclusion in a release note. Gerrit change https://git.eclipse.org/r/99907 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=277d045ee06ca40fca0fb4149b6f30c59ed2fb0b Gerrit change https://git.eclipse.org/r/99906 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/papyrus-rt.git/commit/?id=8ff6cd1873d201f4fe26ba86eac8ed14873db6d4 (In reply to comment #9) > Gerrit change https://git.eclipse.org/r/99907 was merged to [master]. This bug can't really be moved to resolved state until the reference customization problem in Papyrus is fixed, which won't be until the Papyrus 3.0.1 (Oxygen.1) release. If Papyrus-RT 1.0.1 is targeting Oxygen.1, then perhaps this bug should now be re-scheduled for 1.0.1? (In reply to Christian W. Damus from comment #11) > (In reply to comment #9) > > Gerrit change https://git.eclipse.org/r/99907 was merged to [master]. > > This bug can't really be moved to resolved state until the reference > customization problem in Papyrus is fixed, which won't be until the Papyrus > 3.0.1 (Oxygen.1) release. If Papyrus-RT 1.0.1 is targeting Oxygen.1, then > perhaps this bug should now be re-scheduled for 1.0.1? I wonder if we really need to keep it open. I have tested this in the latest Papyrus-RT RCP build (#839), which I assume is based on the latest Papyrus Oxygen nightly build. The UML-RT architecture context is the default as expected. I have also checked the Oomph tester setup and it works there as well. The Oomph end-user setup is also updated (checked by inspection). I suggest that we put this one into resolved. If we absolutely need to track this for a Papyrus-RT release that will be based on Papyrus Oxygen.1, then I would suggest to track that with a separate bug. (In reply to Peter Cigehn from comment #12) Hmm. You shouldn't have been able to test this in the latest nightly build because the Papyrus fix will not be in Oxygen but is only in Oxygen.1 nightlies. We should not be building on the Papyrus nightlies; we need to pin our builds on the Papyrus Oxygen release. (In reply to Christian W. Damus from comment #13) > (In reply to Peter Cigehn from comment #12) > > Hmm. You shouldn't have been able to test this in the latest nightly build > because the Papyrus fix will not be in Oxygen but is only in Oxygen.1 > nightlies. We should not be building on the Papyrus nightlies; we need to > pin our builds on the Papyrus Oxygen release. Yes, I was a bit puzzled myself. But it did work in the RCP, so I assume the target platform for the nightly build of Papyrus-RT uses the nightly builds of Papyrus Oxygen and hence have picked up this change. We have apparently not yet pinned the nightly build to the release of Papyrus (which is not formally released either I guess until Oxygen.0 goes GA). My current settings with the Oomph tester setup is using the latest nightly of Papyrus, but in that context I can't test this specific issue anyway... :) I agree that tracking the Papyrus bug explicitly in the RT context is not important. There will be a readme anyway to cover ad hoc installation methods and that can mention the current limitation in the RCP, that the preference must be explicitly set. Anyone using Oomph can fix it for all of their workspaces anyways. (In reply to Christian W. Damus from comment #15) > I agree that tracking the Papyrus bug explicitly in the RT context is not > important. There will be a readme anyway to cover ad hoc installation > methods and that can mention the current limitation in the RCP, that the > preference must be explicitly set. Anyone using Oomph can fix it for all of > their workspaces anyways. +1 and... Any Papyrus-RT bug that has the "readme" keyword will show up as an entry in the readme/release note document (currently on the wiki - I need a link from the download page...). If I read the bug and I'm not sure what to write or I feel it is missing information, I _will_ ping those who were involved with the bug. Verified to be fixed in the Papyrus-RT RCP build #839, which is based on the latest Papyrus Oxygen nightly build. The UML-RT architecture context is the default as expected. The Oomph end-user setup is also updated (checked by inspection). Closing as verified fixed. Release note added |