I have created an Eclipse4 RCP application and I would like to be able to launch multiple instances. By default when a second RCP instance is launched it says "The workspace is already in use". I know that it is possible to use options so that the application runs with no workspace but in my case I still wont to preserve the layout of the application. So is there a way to avoid workspace lock or to manually save the application state somewhere?
Thanks
Only one instance can use a workspace at a time so you would need to use different workspaces for each instance.
It is possible to set the workspace location during startup. The #PostContextCreate of your LifeCycle class is a suitable place to do this.
Use something like:
Location instanceLoc = Platform.getInstanceLocation();
instanceLoc.set(URL of workspace location, false);
Related
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
My friend and I need to use the same Eclipse workspace. I've put it on an AFP server, so we can both mount the volume and use the workspace there. But will that work without problems as long as we are not editing the same file at once? For example, if there are classes Starter and View, could I be editing Starter.java and saving the project while he edits and saves View.java?
I know that Eclipse cannot normally use workspaces on AFP due to a bug. I had to add "-Dosgi.locking=java.io" to the eclipse.ini file to make it work.
Yes. But you will need to change its configurations to not lock the workspace. This is the default behaviour.
This is the option:
-Dosgi.locking="none"
Use it in your vmargs or in ini file. I do not need to mention you and your friend need some discipline to not be caught by side effects of this solution.
For example, if both are working in file A, when the first save eclipse will ask if you wish update with system file changes. If you click yes your changes will be lost.
To test an eclipse application I have written a test suite that dynamically discovers available test cases at runtime by searching for test projects stored in a subfolder of a given bundle, looking like this:
my.plugin
src/
fixtures/
p1/
p2/
Each fixture is a fully fledged eclipse project. At runtime my suite discovers p1 and p2 and creates a Test for each. Then each test imports its fixture into the workspace on setup, then runs the actual test code and deletes the fixture on teardown. So far this works great, I just dump another fixture to add a new test. No need to write more code for new tests. Yay!
My problem is now that all this runs against a clean workspace with default preferences. What if some of my fixtures need specific preference settings in order to be useful? I somehow would need to provide those custom preferences with the fixture and make sure they are loaded in the test setup for the fixture and restore the default workbench preferences on teardown. What's the best way to do this in eclipse?
I'm not sure if this is the best solution, but I would do something like this:
Let the user choose (in the settings) if the test should be run in a clean workspace or not. If not, just use the current one, so the users can apply settings there. I think this is reasonable, as test running is usually done in the same workspace as the actual project to be tested.
You can access the current workspace by calling ResourcesPlugin.getWorkspace().
If you want to use project settings only, then the solution is simple. Just create a .settings folder in each project and populate the appropriate org.foo.bundle.name.prefs file.
Things get more complicated if you want to have workspace settings. I would recommend looking at the org.osgi.service.prefs.Preferences and org.eclipse.core.runtime.preferences.IScopeContext APIs. Eclipse uses a hierarchical approach to providing preferences. You can set a hierarchy of scopes, eg- Default, workspace, and project scopes. Each scope has one or more nodes and each node has a set of key-value pairs.
So for example, you generally will look up a preference, say the source level compiler property inside a particular project. Here are the steps that this goes through:
Create the scope hierarchy, typically the root is default, then workspace, then the project.
Get the org.eclipse.jdt.core node from the bottom scope.
Ask the node for a value associated with a key.
If this node has a value, then return it, otherwise go to the node from the next scope.
If none of the scopes contain the key, then return some default value.
Your best bet for doing this work simply and not using internal Eclipse APIs is to use a org.eclipse.ui.texteditor.ChainedPreferenceStore instance. You will create the lookup hierarchy of IPreferenceStores that you want to get your preferences from and one of them will be a custom IPreferenceStore created by you that will supply the extra preferences for your project.
Now, of course you need to ensure that all places that require these custom preferences are able to have a custom ChainedPreferenceStore passed in.
I write code in several languages (Python, C, C++, and Java) using Eclipse. Is it possible to designate a directory on my machine (say /home/workspace/) as the "primary" workspace for any Eclipse session, but then to have subfolders, /home/workspace/python, /home/workspace/java, etc., in which I can create new Eclipse projects.
I don't want to have to navigate menus and select different workspaces for each session of Eclipse that I start up. I would rather just always have permission to manipulate any projects from a variety of folders at any time, but I can't find a clear answer about whether this can be done and how to do it.
As I understand your question; You want to have one workspace, but be able to code in several different languages without switching workspace but at the same time keep the projects separated?
First I would suggest you consider several workspaces, I find it convenient to keep settings and projects in separate workspaces. I rarely have to switch language that often.
But. I think what you want to do is to keep several working sets. You create one java working set, one C++ set and associate your different projects with a working set. Then you can minimize the java working set when you are running C++. For working sets you dont need any subfolders on the harddrive.
You might also want to look into Mylyn. Its a great tool for those who often are switching context. It saves the context (eclipse perspective, open files, etc) as associated with a task.
How about setting Eclipse to prompt for the workspace at launch? It wouldn't allow you to work in two languages at once, but should do the trick otherwise.
An Eclipse workspace can contain projects slated for different languages and those projects can live anywhere on your hard drive. There are at least two ways to do what you want. When creating a new project, uncheck the Use default location checkbox and browse to or specify the folder where you want your project to live. If a project already exists import the project into the workspace using the File->Import menu option and then select Existing Projects into workspace. In the next screen make sure the checkbox for Copy projects into workspace is not selected. This will leave the source files in the original folder.
In the Project explorer view, all the projects are going to look like they live at the root level. However you can group related projects into working sets. Then select just the working set you're interested in and all the others will disappear from view.
A warning is in order if you make use of eclipse variables in external tools (and possibly elsewhere). The syntax you use for paths needs to be adjusted. For example with projects outside the workspace this syntax ${workspace_loc:/MyProject/MyFile.txt} is no longer the same as this syntax ${workspace_loc}/MyProject/MyFile.txt