TiStudio 3.2 (based on Eclipse):
Is there a option to save current state of workbench? I mean: opened editor windows, layout, etc.
Per project would be fine.
Everytime I switch projects, those states are lost and I cannot see any option where to set them.
Answering my own question:
install mylyn eclipse plugin.
It provides a task focused workflow that remembers contexts of the workbench for every task.
Really good way of changing contexts.
Take a look at this tuto: http://www.vogella.com/tutorials/Mylyn/article.html
Depending on which workspace I'm currently using and for all I know the position of the moon eclipse turns on and off the built in shortcut for refreshing (F5). If I look it up in the settings it's still set. Yet if I right-click on for example a project I see "Refresh" instead of the normal "Refresh (F5)".
Is anyone else having the same problem or am I an annoyingly unique snowflake?
The debugger’s Step Into wins over Refresh: Eclipse bug 246483
Do you have any additional plugins installed? I guess there might be a conflict (if two plugins install the same shortcuts in the same context, none of them will work) Can you check the Error Log view for any warnings on the conflict?
Also see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=205748
https://bugs.eclipse.org/bugs/show_bug.cgi?id=323959
You can turn on automatic refresh in Eclipse, then theoretically Refresh won't be required at all.
Preferences -> General -> Workspace -> Refresh
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.
What is Eclipse doing when building workspace process is running? Can i disable it because it is taking a long time to complete and i dont know if it is necessary. Thank you
Building workspace is about incremental build of any evolution detected in one of the opened projects in the currently used workspace.
You can also disable it through the menu "Project / Build automatically".
But I would recommend first to check:
if a Project Clean all / Build result in the same kind of long wait (after disabling this option)
if you have (this time with building automatically activated) some validation options you could disable to see if they have an influence on the global compilation time (Preferences / Validations, or Preferences / XML / ... if you have WTP installed)
if a fresh eclipse installation referencing the same workspace (see this eclipse.ini for more) results in the same issue (with building automatically activated)
Note that bug 329657 (open in 2011, in progress in 2014) is about interrupting a (too lengthy) build, instead of cancelling it:
There is an important difference between build interrupt and cancel.
When a build is cancelled, it typically handles this by discarding incremental build state and letting the next build be a full rebuild. This can be quite expensive in some projects.
As a user I think I would rather wait for the 5 second incremental build to finish rather than cancel and result in a 30 second rebuild afterwards.
The idea with interrupt is that a builder could more efficiently handle interrupt by saving its intermediate state and resuming on the next invocation.
In practice this is hard to implement so the most common boundary is when we check for interrupt before/after calling each builder in the chain.
You can switch to manual build so can control when this is done. Just make sure that Project > Build Automatically from the main menu is unchecked.
if needed programmatic from a PDE or JDT code:
public static void setWorkspaceAutoBuild(boolean flag) throws CoreException
{
IWorkspace workspace = ResourcesPlugin.getWorkspace();
final IWorkspaceDescription description = workspace.getDescription();
description.setAutoBuilding(flag);
workspace.setDescription(description);
}
For anyone running into a problem where build automatically is unchecked but the project is still building. Make sure your project isn't deployed to the server in the server tab and told to stay synchronous.
Are there any low-hanging fruit regarding some more efficient way to run and test Eclipse-plugins (within the PDE)? Besides slimming down the Eclipse-configuration, which has already been done.
I usually minimize my launch configuration itself (not sure if that is what you are doing). Here's how I do it:
Create a new launch configuration
Go to the "Plug-ins" tab
Select "Launch With:" -> "Plug-ins selected below only"
Click on "Deselect All"
Select only the plug-ins you are debugging from your workspace
Optional: You can uncheck "Include optional dependencies..."
Click on "Add Required Plug-ins"
Save the configuration and launch
Now, this might not work in the first shot. This probably means you have an issue with the defined dependencies. This is also a good test for that as well. Fix it, relaunch, and it should run much smoother.
I use Launch As: Eclipse Application and I don't find it to be too bad. I've found that changing the plugin.xml (or fragment.xml) always requires you to quit and respawn to pick up the changes, but changing Java doesn't always as the changes can often be hot-swapped in. (PDE is good at warning you when it can't.)
I'd like it if Eclipse could dynamically insert my plug-ins into the running environment -- it can do this with regular plug-ins. As for speeding up the edit-compile-debug cycle, I normally prototype my work in small SWT / Swing applications before integrating them into the full product, but this might not work in a lot of cases.