Community
Participate
Working Groups
Hello, I have an E4 app that updates itself at startup, based on an update site. When the application finds a new version and updates itself, the persisted state of the previous version is kept and still used after the restart. This can be inconvenient because some kind of changes (for example, Key bindings) are not updated to the new version. To solve the problem, I had to delete the following file and restart the app: .metadata/plugins/org.eclipse.e4.workbench/workspace.xmi I think that the framework should force a refresh of the workspace when the application is updated, otherwise the users have to clear the workspace themselves, which is something they should not worry about. Another good feature would be to provide a way to refresh the workspace.xmi not at every update but when a certain condition is met or a certain component says so. That would leave the decision to the application developper. Finally, the ideal solution would be to compare the workspace.xmi and update the components that have been changed between the two versions but leave those that have been persisted by the user. This way each user would keep its customizations through the update and the developper would still be able to make changes to the XMI. This bug started as a thread on the E4 forum: http://www.eclipse.org/forums/index.php/m/1269045/ Cheers, Sébastien
(My app's target is Eclipse 4.3.1. I have not tested the behavior with more recent versions.)
(In reply to Sebastien Pennec from comment #0) > I think that the framework should force a refresh of the workspace when the > application is updated, otherwise the users have to clear the workspace > themselves, which is something they should not worry about. The default behaviour that we want is to *not* clear the workbench.xmi file, so upgrading doesn't trash user perspectives or other customizations. But RCP apps can request that they don't save their workbench.xmi between sessions already. Wiping it out on upgrade would wipe out all perspective changes, etc, but that can already be done by simply requesting not to persist state. Is that not what you want? PW
Paul Webster from comment #2) > (In reply to Sebastien Pennec from comment #0) > > I think that the framework should force a refresh of the workspace when the > > application is updated, otherwise the users have to clear the workspace > > themselves, which is something they should not worry about. > > The default behaviour that we want is to *not* clear the workbench.xmi file, > so upgrading doesn't trash user perspectives or other customizations. Correct but sometimes you want the upgrade to trash the persisted state! > > But RCP apps can request that they don't save their workbench.xmi between > sessions already. Wiping it out on upgrade would wipe out all perspective > changes, etc, but that can already be done by simply requesting not to > persist state. Is that not what you want? > The problem is that you only want to trash it when you install a new version of your product but on starts without an update you want it to persist changes. I think the requested behavior is a legal enhancement which we are not supporting at the moment.
Thank you Paul for your answer. I understand that keeping the persisted state is important. However, keeping the previous persisted state prevents any modifications be made to the workspace.xmi. In my case, I had a binding problem, and it was not corrected after the update because my app still relied on the previous workspace.xmi. It was corrected though after I deleted the file. I would like my app to persist its state between sessions, so that my users can open different parts and get them back after a shutdown/relaunch of the app... however I sometimes want to change the workspace.xmi and at those times I think the framework should help me cleaning the state. At the moment, there are two possibilities: either clear the state each time, or keep it (what seems to be) forever. My request is to have a third possibility that allows me to make changes to the file and see those changes after the update.
> The default behaviour that we want is to *not* clear the workbench.xmi file, so > upgrading doesn't trash user perspectives or other customizations. A question about this: how do you change something in the application.e4xmi without clearing the workbench.xmi? The binding changes, at least, are not reflected after the update.
I released my app today, and my clients didn't see a new menu item that I've added to the app. I made one of them delete the workspace.xmi file, and then the menu item appeared. For my next releases, I will hack the app to delete its own workspace.xmi in case it's updating to a new version... but I don't think this is the right way to do it... I really think that the framework should handle such situations...
Thomas, Paul: I really think that this issue should be planned for Eclipse Mars. It currently poses problem when shipping apps, and it seems fair that the framework should offer a way to do this. What's your opinion?
Today I found that my RCP app was missing a menu item. Why? I've no idea. I had to manually delete the workbench.xmi file and some other files in the config area. My use case is simply something like a "Something screwed up, Reset!" option that will: a). Delete the org.eclipse.osgi folder in the app's config area b). Delete the workbench.xmi file c). Not re-persist all this stuff for this one time so that the user can safely close the app and restart it Is this possible?
Hi Phillipus, I've done something that looks like this in my app. Basically, it does two things: make sure that at update-time the workbench file is erased, and provide a menu item that acts as a "panic button" if something goes wrong in the normal use of the app. The menu item indirectly creates a dummy txt file in the app's root folder, then restarts the app. At startup, if the file is found, the workbench file is deleted thanks to a LifecycleListener's @PostContextCreate method. This is obviously not a great implementation... but it works fine. I still stand by the fact that the E4 framework should provide a way to clear the persisted state at update time... and I regret that my previous comment regarding the inclusion of this bugzilla entry in the Mars planning was not answered...
I wanted to ping this bug, but to also contribute something usefel: Tom posted an injectable service a while ago, that could solve this issue [1]. I have not tried it so far, but to me it looks like a good solution that could also be part of e4. @Tom, would you consider contributing your implementation? [1] http://tomsondev.bestsolution.at/2014/06/17/restarting-an-e4-application-with-the-intial-workbench-e4xmi/
I just wasted some time wondering why a simply change of a command name didn't show up in a runtime workbench. Running with -clearPersistedState worked around the problem. I think there's a conceptual bug involved here: Why do I have to discard valuable state (perspective layout etc) just in order to refresh a cached value, which is actually provided by an extension (command name)? This looks flawed to me. Note, that in my case I intentionally did not externalize the command name, because this particular application is not used in several languages. Maybe that's why I'm seeing the command name served from workbench.xmi?
Resetting user state each time the model is updated is a no-go for production applications. If not addressed in the framework this bug will result in multiple adopters developing home-grown merging of changes into the application model. Thomas, any ideas on how this should be ultimately addressed? Is it feasible to do it in the platform?
@Pawel: I am also in favor of a way to update the workbench description file - as opposed to just replacing it, thereby discarding valuable user customizations. You are mentioning "home-grown merging of changes" solutions. Are you aware of specific solutions/projects? They would be interesting workarounds, and I'd rather not reinvent the wheel here.
Nicolas, I'm not aware of anything available.
I have a similar problem. Changing an icon for a eclipse view does not get updated in the workbench.xmi file. Everytime I start Eclipse and the specfic view is visible but not active, I see the old icon, activating the view updates the icon. References of this view in workbench.xmi point to the old icon.
We have an application that is distributed using an installer (so no mid-live cycle updates). I store the application version in a file and when booting I compare version number of the executed application with the stored version. If they differ I set the environment variable clearPersistedState=true before running the workbench. As a consequence customized layout is discarded. However, since the user has explicitly updated I don't consider that to break the user experience. It's not the most elegant solution but it works for us
I’m wondering, why this gigantic drawback isn’t of importance for the platform team. Do you really think, one can build professional software on the basis of Eclipse RCP and tell the customer he has to delete their workspace after each update? Some customers spend a lot of time to shape their perspectives and don’t want to lose everything just to be able to see a new menu item implemented in the last update! Using flags "-clearPersistedState" or "-persistState=false” is NOT the solution. The customers WANT to have the workbench state persisted. But they also want to get updates and new features for their software. The only reasonable solution in my opinion would be to provide some kind of "Reset View" action. This action should wipe out the persisted state of the view part from the "workbench.xmi" and force the app to load the part from the application model again. It should be also possible to trigger this "logic" programmatically. So the best place for it would be a service (like "EModelService").
(In reply to Willy Michel from comment #17) > I’m wondering, why this gigantic drawback isn’t of importance for the > platform team. Do you really think, one can build professional software on > the basis of Eclipse RCP and tell the customer he has to delete their > workspace after each update? Some customers spend a lot of time to shape > their perspectives and don’t want to lose everything just to be able to see > a new menu item implemented in the last update! Using flags > "-clearPersistedState" or "-persistState=false” is NOT the solution. The > customers WANT to have the workbench state persisted. But they also want to > get updates and new features for their software. > > The only reasonable solution in my opinion would be to provide some kind of > "Reset View" action. This action should wipe out the persisted state of the > view part from the "workbench.xmi" and force the app to load the part from > the application model again. It should be also possible to trigger this > "logic" programmatically. So the best place for it would be a service (like > "EModelService"). Willy: I couldn't agree more. I love Eclipse, both the IDE and its lower-level frameworks like SWT and JFace, and yes - RCP too, despite its numerous (too many) quirks and general bloat. To piggyback on your answer, the 2 main issues we face at our company are: - The one raised in this thread, mainly the tight coupling of the "UI" state and the "UI" definition. Deletion of the persisted state after a menu tweak or part addition to the layout became quickly unacceptable. We overcame that issue by saving a portion of the current layout to disk, and restoring from there if needed, ie after a -clearPersistedState start-up. It doesn't run 100% smoothly, but it works well enough in most cases - also the user always has the ability to reset their UI state at the click of a button, should anything go bad (in which case we end up with the same issue of UI state loss, but it would affect a tiny fraction of the instances as opposed to 100%). I suggest you implement a similar solution as a temporary workaround. - The other issue is the long start-up time that RCP apps face. I would guess that tons of products out there use Eclipse RCP for its advanced and portable UI framework (docking, perspectives, native components, etc.), not really for its pluggable platform -- which I guess is one reason for the overly long init time. A streamlined, UI-focused only, fast version of RCP, something like a "Rich Client Framework", aka an intermediate between JFace and RCP, could be the solution. That problem is not directly related to this thread is related to the issue: RCP is more than just a UI framework; plugins expect a clean slate after reset. I think that's why things were designed like they were.
@Nicolas: thanks for your feedback and for the workaround! I’m currently working on another workaround: using "Reset View" action as mentioned above. This is not really a proper solution, but I want to provide at least something to my customers to avoid the necessity to delete the workspace. The "solution" has a lot of side-effects therefore it’s rather a hack. Actually I'm expecting from the framework that all changes on the application model are properly merged into the persisted model. Somehow the same behavior was possible in Eclipse 3.x.
This issue is, I think, mis-named. I'm new at Plugin/RCP development, so maybe I'm way off base here... But it seems to me that the issue here is not that we need a way to clear persistent state on updates, it is that the composition of the application or plugin should not be considered a "user-customization" in the first place. It has always struck me as extremely odd that when developing a plugin, you have to tick the "clear workspace" option on the target in order for your changes to show up. My plugin's design should not be a feature of the workspace, it is a feature of the plugin (or RCP app). Since this is a fundamental architectural issue, I'm wondering what the project leadership thinks about this. There haven't been any comments from that neck of the woods in close to 3 years.
(In reply to Kirk Stork from comment #20) > This issue is, I think, mis-named. > > I'm new at Plugin/RCP development, so maybe I'm way off base here... > > But it seems to me that the issue here is not that we need a way to clear > persistent state on updates, it is that the composition of the application > or plugin should not be considered a "user-customization" in the first place. > > It has always struck me as extremely odd that when developing a plugin, you > have to tick the "clear workspace" option on the target in order for your > changes to show up. My plugin's design should not be a feature of the > workspace, it is a feature of the plugin (or RCP app). > > Since this is a fundamental architectural issue, I'm wondering what the > project leadership thinks about this. There haven't been any comments from > that neck of the woods in close to 3 years. Exactly! +1
Seeing the keyword "helpwanted" is another quirk on this bug. I'm sure whatever patch could be provided by a contributor will be rejected by project committers. What we need is not a contribution, but a concept. My understanding is: it should be possible to distinguish different kinds of information in workbench.xmi and API to selectively reset some parts of this information (e.g., cached menu definitions, key bindings) while retaining other parts (e.g., user customization of perspectives). Mix it all up with a hook to invoke selective resetting from an update operation.
It's been another 2 years since this was last commented on. We need to store the cache and also update it. By clearing the cache we lose the users layout that they have selected. By not clearing the cache the users won't see any new views etc that have been added. This is not suitable for a production application. Is this going to be considered a priority at any point?
A handy implementation of this would be to detect if the 'CTRL' key is pressed when the applications starts, and in this case, consider that clearPersistedState should be applied.
For the last several years our approach in our RCP app "Archi" is to have a "Reset to Defaults" button that restarts the app and deletes the workspace.xmi file. Never did understand why app UI, menus, commands, etc are stored in this file when these are all declared in a plug-in and prefs files. Two states get out of sync.
Is there a way to selectivly change the content of workbench.xmi during startup time?
@Udo: I think, it's a bad idea to manipulate the xmi file directly. But there is an API to get access to particular elements of the workbench model. Have a look at "EModelService" for more details.
Ok, I suppose you are right. As the concrete instance of the model is not public I have to guess the childrens and their attributes myself. I need to change the user filters of the project explorer but I could not find any preference value which I could change vie plugin_customization.ini for my RCP product. That's why I thought chaning the workbench.xmi file directly would work. I added a IStartup hook but my changes are not recognized -> dead end. But how do I change the Project Explorer preferences?
I found that Window/New Window creates a new window with a fresh copy from the model. Subsequently closing the "old" window has the same effect as running with -clearPersistedState but without the associated complexity. I think this is a promising path to the solution of this issue because all this could be done programmatically.
My two cents worth re "the concept"; am using Archimate and all I want is to set a specific model and view via launch parameters, and this seems hard to do. My workaround is to avoid workbench.xmi entirely, and I clobber the path to my model file in models.xml before and after running the UI: <?xml version="1.0" encoding="UTF-8"?> <models> <model file="/home/me/xxx.archimate" /> </models> Its not ideal (no views, probably orphans entries in xmi file), but its more complicated than what I have time for. But to the concept idea, I need control over what is coming into the UI, over any views I might have previously opened. UI persistent customisations is nice, but for me it is all first dependent on what model I want in the UI. Cheers,
Eclipse Preferences framework has exactly same problem solved by separation of default values and customized values in different scopes(containers). Default scope is repopulated with hard-coded values on every Platform startup. When value is modified by user, it is stored in customized scope. When value is read and is absent in customized storage, a default is used instead. This approach allows default values to be volatile across product upgrades while still persisting user-provided data.
