I'm using Eclipse (PDT) as primary IDE on different machines. (like at home, laptop, in office, etc.). How could I share the Eclipse and project configuration pragmatically between multiple computers? Should I version control them, or is there any easier way to do this?
How do you ensure to use the same good and old even so up to date config all of your computers?
Sharing eclipse specific settings across workspaces:
${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings${new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settingsThis is going to make sure that the ${new_workspace} is having the same configuration as the ${old_workspace}
Update in case of any issues.
\.metadata\.plugins\org.eclipse.core.runtime\.settings directory ?" - to peakit : it's not as simple as that - the ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings contains also workspace settings and has other peculiarities - see my analysis here –
Rojas Another option is export/import:
File->Export...->General->Preferences, check Export all, and choose file to save them to (prefs.epf for example)File->Import...->General->Preferences , choose your file (prefs.epf), check import allThat worked great for the original author of this tip: he had his code formatting, code style, svn repos, jres preferences imported.
Edit: On Eclipse Juno this works poorly. Some preferences silently do not carry over such as save actions.
It's a relatively new project, but it looks like Eclipse Oomph was created for exactly this reason. Through this tool you can create a unique configuration that can be shared with others. I have not used it (yet), but am planning to:
I had to work on multiple workspaces simultaneously and there were a lot of preferences to be set each time I create a new workspace. I created a template workspace and created all the the required settings in that template workspace.Whenever I create a new workspace, I create a simlink of the {new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings to point to {template_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings. So, when you edit any preference in any of the workspaces, it will be replicated across all other workspaces.
I created this function alias in my .profile so that once I create a new workspace, I run this function in my command prompt with my new workspace name as argument so that the link is created.
function eclset(){
present_dir=`pwd`;
cd {parent_to_workspace}/$1/.metadata/.plugins/org.eclipse.core.runtime ;
rm -rf .settings ;
ln -s {parent_to_workspace}/template/.metadata/.plugins/org.eclipse.core.runtime/.settings .settings;
cd $present_dir;
}
You can actually set many project specific settings that can be checked into source control. For small projects, this works really well. For larger projects, we decided to have a single file that we used for all of our projects and checked into a separate "assets" project that maintained things that developers needed to get started working on our project. This also included things like licenses and other required files.
As of Eclipse Neon (and possibly Mars), you can copy the following two directories, to share your workbench and settings/preferences amongst your different workspaces:
[workspace]/.metadata/.plugins/org.eclipse.core.runtime/.settings
[workspace]/.metadata/.plugins/org.eclipse.e4.workbench
UPDATE: These two directories still exist in Eclipse 2022-03 (note the change in version naming, from astronomy-related to YYYY-MM)
There are two questions here. First, there are project definitions, the .project files and project specific settings. Personally, I like those in my source control, as it makes checking out a project and setting up an IDE much easier.
Second, you have the workspace settings. You will see a lot of questions in this area. I suggest taking a look at Pulse: it is an enhanced Eclipse distribution that can, among other things, save your workspace settings and sync them with multiple machines or team members.
You can also copy the .prefs files from ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings to a folder called .settings in the root folder of your project and then add it to SVN (or CVS or ...)
That way the settings will get distributed to all developers along with the source code during an Update.
i had the same problem.
my approach: storing project data in a directory managed by owncloud
The Project X is created at workstation A, with a custom path pointing to a new sub directory of my ownCloud hierarchy. The default workspace is still residenting on the file system of A.
When I'm sitting at workstation B I open the default local workspace (local on B) and create a new project using the existing sources in the "synchronized" ownCloud directory.
Just click refresh any time you fire up eclipse and you have the current project data. Synchronisation runs in the background automagically, so take care when you have finished working to close eclipse and give ownCloud a chance for uploading the new files to the ownCloud server.
Tomcat or other Servers are running local, the config is copied manually between the machines via scp. This happens only if there are changes in the server setup, which is not very often.
I had no compatibility problems using NEON 2 (arch linux) & NEON 3 (download an running on debian stretch) with different JDK's yet.
Best regards Armin
Simply copy the directories
${old_workspace}/.metadata/.plugins
from an existing project to the new one.
That worked well within (rather simple) PHP projects.
You can use Eclipstyle to clone preferences of one workspace to your other workspaces. You can also export your preferences and clone them later.
© 2022 - 2024 — McMap. All rights reserved.