Solution for eclipse project portability? - eclipse

In my work env, I have setup the eclipse project in my PC which includes some Workspace Environment Variables, setting Project dependency and setting User library (from a common network location).
Now my fellow colleague who has checked out the same source code goes through same steps.
Is there a way to reduce this clutter ?
From what I could see is that only the source project location is different from my PC and other PC.
Is there any that I could change my project locations during eclipse startup in the other PC ?
So I could easily retain the same settings on another PC with same workspace.

First steps:
Use a version control system to store and share your projects.
Check in everything that is contained in your workspace. That is not only your source code, but also the settings files in the hidden settings folder.
Do not use Window -> Preferences to modify Java settings (or other build related settings). Instead always use Project -> Properties to modify build related settings.
Never ever refer a network share or another location outside of your workspace. If you need a jar file which is currently on a network share, then check it into your version control system and afterwards check it out in your Eclipse workspace as local file.
Second step:
Use Maven for project materialization, dependency and other management.

Related

Eclipse PyDev : using environment variables to share Workspace between computers

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.

what should keep in mind before providing work space for eclipse?

This is how the workspace assign on an eclipse
My Web project run only when my project is at c:\Ampps\www\myProject but eclipse contains it on C:\Simple\workspace\myProject. My problem is I want to run project and the workspace is different. What is the things keep in mind before choosing the workspace. And what are the alternatives if the wrong workspace choosen ?
Eclipse does not require your projects to live under your workspace folder. Therefore you are allowed to have a project and workspace as you describe.
When creating a project, uncheck the default location checkbox in the wizard and select your truly desired location.
My only recommendation on workspace location is to have it on a local drive and don't have it as a sub directory of any project in your workspace.

common workspace setup in eclipse

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.

How can I have per project Debug Configuration in Eclipse?

I have configured some VM arguments inside the Debug Configuration. However, these settings are saved in .metadata\.plugins\org.eclipse.debug.core\.launches\Program.launch, which is outside the version control. Indeed, the whole .metadata folder is.
But this is something I wish to be shared amongst all the devs working on the project. In other words, I want per project Debug/Run Configuration.
Is it possible?
The launcher (.launch file) can be stored outside of .metadata: go to "Run → Run Configurations...", choose your launcher, and in its "Common" tab choose "Save as: Shared file". This will save the .launch file in the chosen folder, and then it can be committed to your version control system.

Publishing a common workspace setup

I want to set up certain configurations and preferences in IBM RAD (or say eclipse) so that a big team will be able to use the set-up already done. this would reduce the inconsistencies and rework effort in the team.
Preferably I want to keep that in subversion.
Right now, when created a workspace in my personal desktop and added it to SVN, everytime my team mates check it out obviously the .metadata and other eclipse internal files change based on their input.
Is there a standard practice/process to publish a common workspace setting in RAD/Eclipse?
Thanks
There are probably 2 things that matter most when getting yourself or someone else a new workspace. Getting the preferences set up, and checking out the appropriate source code.
1a) you can set up a workspace, and then export all the preferences. That provides a eclipse preference file that can be imported into a new workspace
1b) use project specific preferences where possible, as those will get checked into your SCM
2) the projects you work on can exported to a Team Project Set File. That can be imported into a new workspace.
Check them all into a releng project in your SCM. In this context, a releng project is just a project that has all of the build information in it. Then a new workspace setup involves checkout out the releng project, and importing the PSF and the preferences file.
Or have a look at Workspace Mechanic for Eclipse: http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
If you are using Websphere RAD 7.5 it allows you to export a backup of your server profile preferences. So all of that configuration for databases and classpath can be backed up. I would try deploying that to your team and see if that helps.
Right click on the server, then click Server Configuration> Backup .
Hopefully that does the trick.