We all know that by default eclipse saves application state in workbench.xmi and then recreates perspective only if this file is absent. However, I've got a project on e4 which ignores this file even though it exists and -clearPersistentState is NOT specified in arguments. I think there should be some piece of code somewhere responsible for this but the project is too big I don't know how to track it down. My goal is to make this app to use workbench.xmi once again to restore perspective.
To investigate why this happens I want to know which eclipse method is responsible for perspective restoration so I could make sure that this project at least launches this method. That's the main question.
The less main and the less clear question is how this default restoration behavior can be avoided? I mean where should I look for the possible source of this problem? Could there be some option in some .xml which makes the project forget about workbench.xmi? Could it be some sort of startup handler which manually restores default perspective? Maybe some hint about which methods are possibly should be involved in this so I could search for them. Any help is appreciated. Thanks in advance.
-UPDATE-
So it turned out that the problem arises because the project UI is defined in fragments rather than in main Application.e4xmi and eclipse has a bug due to which fragments UI merge with main application after previous state restoration thus replacing restored settings with predefined ones. This bug is discussed in this thread.
This useful article describes how one can manually save and load various application components. Another useful source of inspiration is the source code of ResourceHandler itself.
Add apply="initial" to fragment tag in your plugin.xml to restore stored perspective from workbench.xmi
Example:
<fragment
uri="fragment.e4xmi"
apply="initial">
</fragment>