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.
The main E4Application class controls loading and saving the application model.
E4Application calls a class implementing IModelResourceHandler to load and save the model and the persisted state. It is possible for an application to use its own version of IModelResourceHandler but normally the default org.eclipse.e4.ui.internal.workbench.ResourceHandler is used.
ResourceHandler uses the clearPersistedState, persistState and the deprecated deltaRestore options to control loading the persisted state. These values can be set by command line options.
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>
I searched all day long yesterday but i didn't found an answer to my problem.
I would like to hook the workspace selection process of eclipse in order to forbid spaces in the path of the workspace location (typed in the workspace dialog selection launched at startup).
Do someone know how i can achieve this ?
Thank you for your help.
The workspace selection is done in org.eclipse.ui.internal.ide.application.IDEApplication which is the main IApplication class for Eclipse. This does not have any way to change the workspace validation.
The only way to change this would be to define a new IApplication class and build a custom RCP version of Eclipse based on that. I don't think this is possible without accessing some internal Eclipse classes so would violate the Eclipse API Rules of Engagement
I have a lot of Eclipse run configurations that I frequently access during my daily work (things like doing a maven clean build for various projects, running a test gui, deploying apps etc etc). The Run Configurations Window (accessed via Run->Run Configurations) is reasonably good and supplies me with most of my needs, but:
I hate having to manually open it up every time I need to run something.
The window is modal and that I can't easily access other Eclipse features while editing a configuration.
It loses any filters that I have applied previously.
Is there a way to have this window fixed in a view that I can access at any time, and that it maintains my context? It really seems to me that this feature was designed with little regard for the "Eclipse way of doing things".
I know about setting configurations up as "favourites", but I have probably close to a hundred of these configurations, and the favourites menu is simply not designed for that amount.
I have been using eclipse for a few years. I typically use just ONE workspace and have several projects for all of my perforce branches. I close the ones I'm not working on, open the one I am interested in.
The caveat to this approach is that I have to manually close empty editor tabs every time I do this.
Am I approaching this the wrong way?
I'm really not a fan of having multiple workspaces as then I have to setup proejct variables for each new workspace.
Is there a way to associate the currently open set of editor tabs to the current project(s)?
Thank you for your time.
-Dennis
Is there a way to associate the currently open set of editor tabs to the current project(s)?
AFAIK, no. However, you can associate the editors to a task by using Eclipse Mylyn. This way when you switch to an old task, it will set the editors and package exlorer to only show what you worked on the last time.
If you are working with defects from Jira or Bugzilla or a few other systems, these defects can automatically be imported into mylyn and will allow for very easy context switching.
If you dont get tasks from one of the supported repositories you'd have to manually create the tasks, but then just creating a dummy task for each project you work on would create the effect you are after.
I develop Java code with Eclipse and regularly get this message:
resource is out of sync with the filesystem.
Right-click > Refresh will always clear this.
But why can't Eclipse refresh automatically when it finds this condition? Are there cases where you want the resource to be out of sync?.
If there are such conditions and they don't apply to my work, is there a way of getting Eclipse to refresh automatically when it encounters this state?. (I appreciate that it should refresh as little as it needs to in normal development to increase performance for human developers.)
UPDATE (2012-06-25):
My latest update (Version: Indigo Release Build id: 20110615-0604)
no longer shows
Preferences - General - Workspace - Refresh Automatically
There is an option "Refresh on access" - should I use this?
You can enable this in Window - Preferences - General - Workspace - Refresh Automatically (called Refresh using native hooks or polling in newer builds)
The only reason I can think why this isn't enabled by default is performance related.
For example, refreshing source folders automatically might trigger a build of the workspace. Perhaps some people want more control over this.
There is also an article on the Eclipse site regarding auto refresh.
Basically, there is no external trigger that notifies Eclipse of files changed outside the workspace. Rather a background thread is used by Eclipse to monitor file changes that can possibly lead to performance issues with large workspaces.
Just right click on the file or on the project and click Refresh. The error will vanish. I also faced the same issue and it worked for me.
Window -> Preferences -> General -> Workspace
For the new Indigo version, the Preferences change to "Refresh on access", and with a detail explanation : Automatically refresh external workspace changes on access via the workspace.
As “resource is out of sync with the filesystem” this problem happens when I use external workspace, so after I select this option, problem solved.
This happens to me all the time.
Go to the error log, find the exception, and open a few levels until you can see something more like a root cause. Does it says "Resource is out of sync with the file system" ?
When renaming packages, of course, Eclipse has to move files around in the file system. Apparently what happens is that it later discovers that something it thinks it needs to clean up has been renamed, can't find it, throws an exception.
There are a couple of things you might try. First, go to Window: Preferences, Workspace, and enable "Refresh Automatically". In theory this should fix the problem, but for me, it didn't.
Second, if you are doing a large refactoring with subpackages, do the subpackages one at a time, from the bottom up, and explicitly refresh with the file system after each subpackage is renamed.
Third, just ignore the error: when the error dialog comes up, click Abort to preserve the partial change, instead of rolling it back. Try it again, and again, and you may find you can get through the entire operation using multiple retries.
If this occurs trying to delete a folder (on *nix) and Refresh does not help, open a terminal and look for a symlink below the folder you are trying to delete and remove this manually. This solved my issues.
When you open an Eclipse workspace from within a clearcase view and try to rename the project, you will often get the pop-up warning ... “Resource ‘project’ is out of sync with the file system”. If refreshing the project does not fix the problem, then do the following workaround: a. Open workspace WITHOUT being in a view b. Select the project in Project Explorer c. ClearCase -> Associate Project (project should now look like project [] ) d. Right click project -> Refresh (vob sub-folders should now be empty) e. Right click project -> Rename ... f. Enter New name
Now you can close the workspace, reopen it in a view and refresh the project. You may also dissociate the project if you prefer the project not to be associated with the vob.
A little hint. The message often appears during rename operation. The quick workaround for me is pressing Ctrl-Y (redo shortcut) after message confirmation. It works only if the renaming affects a single file.
If you are a regular Eclipse user than you might have got this error many times. The error simply says, “you’ve made changes in files in your workspace from outside eclipse”. The simplest solution would be to select the project and press F5 (Right click -> Refresh).
if you need more explanation you can read from this web site
I was not able to resolve this error by either refresh or by turning on "native polling" workspace feature. Turned out my project was also opened in two instances of eclipse. Once I closed the other instance, the error went away. So make sure your project is only opened at one place if you are seeing this error.