I have an Eclipse PyDev project (Eclipse 4.7.3a). I want to be able to sync the Eclipse workspace between several computers (and that it works, obviously).
First problem : the Python virtual environment. I have installed it in a folder that is located next to the Eclipse workspace (but not inside it) and is also synced between the various computers.
Since the folders for the workspace and the Python virtualenv are not located at the same point the of file system (I use Linux), my guess the simplest way to achieve this would be to use some kind of environment variable, different on each computer, that would point to the directory that contains all the synced folders.
So how can I set a Python virtualenv using a kind of system environment variable ?
Or is there another way to achieve my goal (sharing and syncing an Eclipse workspace between several computers) ?
This is not currently possible.
The workspace has information which is dependent on the absolute paths and is not really shareable (unless you have a mirror in both computers with files in the same paths on both).
Some configurations can be saved in the project itself or in the user settings (the ones that can do that have buttons in the preferences page to save to a project / show from a project -- but note that the interpreter itself still doesn't have that).
Personally, what I do is save everything possible in the project and commit that to git (so, anyone using the project will use those same settings), and try to use the same paths on multiple machines.
Related
I have Eclipse + PyDev installed on my laptop and desktop, both of which are dual-boot Windows Vista 64 & Ubuntu 12.04. Right now the only 'version' I have fully fleshed out pretty much the way I want it is in Windows on the laptop. What would be the best way to duplicate (and hopefully synchronize) this across both computers and both operating systems? In this case the only one using the account(s) would be myself.
A few suggestions:
If you just want to refine your Eclipse installations with some
common configuration then allow them deviating from that point, you
could copy your workspace folder to all places you want, then switch
to those workspaces from within Eclipse. You can also export your preferences from
within Eclipse using File > Export > General > Preferences, that may work as well,
or better.
If you want to share Eclipse configuration between Ubuntu and Windows, you could install NTFS-3G in Ubuntu, then make Eclipse workspace point to your Windows partition. I'm not sure if Eclipse can deal with this well though (for example JDK path).
If you want to use same configuration for all of your devices and operating systems, and considering you won't be using more than one Eclipse instance at same time:
If you have wi-fi, you could share your Eclipse workspace in Windows then map a network drive letter in the other Windows, and mount a remote network location in your Ubuntus. You could still use second suggestion above for same device.
Alternatively, you could use rsync or similar to synchronize your different workspaces, both when you start and close Eclipse. This way, you move possible performance issues with above option from when you are using Eclipse to when you are starting or closing it.
You sync on start for getting up-to-date with latest changes from other devices, and on close because you want to push the changes you have made to other workspaces as well. In Ubuntu, you could just wrap the sync commands around Eclipse call in a shell script, and in Windows you can do the same with Hidden Start, except that it can hide shell window for you.
You could use services such as Dropbox, Skydrive or Ubuntu One to store your Eclipse workspace and let their client software do the synchronization job for you.
This is what came up to my mind. Maybe Eclipse has something built-in to deal with this other than export wizard, not sure.
What exactly to share
Remember that the workspace is where all your personal configurations reside, including the list of projects you see when using Eclipse. If some of these projects are outside workspace directory you may face path conflicts, for example C:\MyProject present in your PC but missing in laptop. You could keep all your projects within workspace directory for avoiding this though. Also, if you go for the first suggestion, export wizard as said may work better.
I don't think it's a good idea to share only part of workspace, unless you know what you are doing, and I don't see much benefit from sharing whole Eclipse directory itself (which is not possible between Linux and Windows anyway). You can find out where exactly your workspace is located in File > Switch Workspace.
I want to create several workspaces which point to different branches of a codebase.
The problem I am facing is every time I need to create a new workspace I have to do the same configuration for each workspace.
Example:
Setting up tomcat configuration and it's related java options such as library and java agent settings.
A system variable that points to specific folder containg my jar files.
Another system variable
Questions:
is it possible to have these setups done once so that all subsequent workspaces do not need to be configured?
is it possible to export these preferences and import later into any workspace either on my machine or other machine?
System information:
Windows 7, Eclipse 3.5, Sysdeo tomcat plugin, Tomcat 6
While eclipse does have an Export preferences option, it does not export everything and specifically it is not comprehensive enough for workspace duplication.
In the past I have had a lot of success just cloning the physical workspace folder itself.
For example, let's say you have setup the workspace with everything that you want in it. To duplicate it, find out the path of the current workspace folder by going to File -> Switch workspace -> Other. The path shown here in the dialogue that pops up is the current workspace path ( don't press ok yet)
Create a copy of this folder. Now to use this copy, just use it in the above dialogue, i.e., go to File -> Switch workspace -> Other and put in the path of the copy. Press OK and Eclipse shall restart with the new workspace. Now the only thing you will have to do is point the code to a different branch. Rest all the settings should be present already.
This works specially well on the same machine. If you copy this workspace folder it should still work but your mileage may vary.
Setting up Eclipse on each machine I work it a real headache and I want to keep the Eclipse files and configuration in-sync between several machines.
I want to keep Eclipse in sync on OS X, Linux and Windows so I started getting the OS X version of eclipse because it has the app needed for OS X, as for the other two platforms it's easier to launch it.
What questions/problems I have:
What should I not sync?
Where can I put JDBC jar files so they are synced too? Is there a way to load them using a relative path?
Any success stories?
Note: this is not about getting the projects themselves in sync, for this there are all blends of SCM.
You can not share the Eclipse installation directory or the workspace, but the projects themselves are easy to keep in sync using a version management system like cvs, svn, git, etc. I suppose you could store your project contents in a Dropbox folder (or similar file system syncing mechanism) and then just force Refresh when you sit down at a machine that was using those projects, but I've never tried it and would be wary that human error could lead to lost work or corruption of files.
The key is that, although workspaces themselves can't be shared, projects don't have to be located physically under the workspace folder on your file system. That's because the workspace is a logical container for projects, not necessarily a physical container. When creating a project you can specify an arbitrary file system location for the project contents. The default just happens to be under the workspace location. SO on each machine you'd have a separate workspace that imported the project(s) from wherever you are syncing them on your file system. That way the workspace is a tiny container that doesn't require much ongoing maintenance on each machine. I do this locally all the time - I have multiple workspaces on my machine, some of which include the same projects as others.
Most of the configuration of Eclipse is in the Workspace. And unfortunately, all the files in it are platform specific. I've tried doing something like this myself and had no luck. Asking questions in their IRC channel didn't leave me with hope either.
I have couple of different OSs installed. When I try to start eclipse in another OS eclipse starts complaining about workspace being used by 'another eclipse instance'. In case you don't know eclipse uses .lock files for that.
How to fix this?
I see a couple of possible ways to deal with this problem:
Disable .lock file check (It can cause some problems if opening workspace in 2 eclipses at the same time)
To make an empty 'workspace' just to make eclipse happy about all that settings and .metadata and .locks and keep projects elsewhere.
Removing .lock file every time I boot another OS. But what if I'll make a new workspace?
Is there a standard (or just better) solution of this problem?
If you exited Eclipse cleanly, then it should not complain about the Workspace being used.
Or do you want to access a Workspace with multiple Eclipses simultaneously?
UPDATE: Anyway I did this on a Mac, using the same Workspace on a FAT32 partition from OSX, Ubuntu and Windows, and I didn't encounter many problems. Of course remember to set the file encoding and line termination setting project or Workspace wide!
Eclipse workspaces are not designed or intended to be shared across different machines (nor across different operating systems). Trying to do so is certain to cause headaches and possibly even corruption of the workspace. There are things like absolute file paths (and other artifacts) embedded into workspaces that simply are not portable.
The better approach is to locate the projects elsewhere in the file system outside of the workspace; that way you can have multiple workspaces "contain" the project(s). Creating such a project is easy from the project creation wizards (a checkbox labeled like "Use default location" that needs to be un-checked, and an accompanying field that is filled in with the desired files system location). From another workspace, use File > Import > Existing Project Into Workspace to get the project in.
This question was close to mine, but not quite.
I have a Windows desktop and a MacBook Pro. I'd like to be able to keep my Eclipse workspace in my Dropbox folder. The problem is that many project settings change between platforms: references to JREs, JDKs, and other libs.
Every discussion I've seen of this problem seems to suggest taking advantage of the source control system's ignore functionality, so that such-and-such file remains local-only and thus able to remain platform-specific. But when you're working with a real single shared folder, that class of solution doesn't apply.
Have you had luck working with a Java Eclipse project living in a single folder shared over the network, cross-platform?
I have my Eclipse workspace inside Dropbox with all my project folders within, but use the new-ish "Selective Sync" feature of Dropbox to make sure that the .metadata folder is not synced.
This means my Mac and Windows machines have their own .metadata folders but the project folders remain in sync.
Seems to be working so far...
Use source control with individual workspaces. By doing it this way you lose the capability of two developers making changes to the same file. You also run a higher risk of people stepping on each other. With Subversion (or others) source control is free and gives you traceability.
Perhaps the way to have less problems is just to share the source folder, neither workspace settings nor bin folder.
Just put your source folder in Dropbox.
Create the project on site1 and then:
Right click over the project, choose properties
--> Java Build path --> Source tab
--> Link source button
Then create a link to your source folder in Dropbox and assign it a name (e.g. src2)
Make the same for site2.
All your source files must be in your share source folder in Dropbox.
Of course you must configure on each site the settings like libraries and other stuff but this task is less frequently and perhaps desirable because you have two different environments.
For anyone else having trouble getting this to work, try File->Import->General->File System. Be sure to select Create links in workspace from the Advanced options. Seems like the cleaner solution and you can keep using your usual workspace.