I just want to know if there is a way to duplicate an eclipse workspace including the projects inside.
EDIT : Copying files doesn't work for me, I'm looking for an automated process or a plugin.
I am not aware of any automated solution. The worskpace itself (in the .metadata directory) contains absolute paths and that's the reason why you cannot simply copy it.
I always duplicate workspace by creating a new one. It may be more complicated, but it always works. I have all the eclipse-project files (.settings directory) in a versioning system which makes creating brand new workspace relatively simple. After creating empty workspace, I just use Import -> Existing Projects into Workspace.
Not exactly copying a workspace, but you mentioned what you are looking for is an automated process, so Eclipse Installer (a.k.a. Oomph) might be an option. It allows you to provision developer workspaces including cloning VCS repositories, setting up projects and pre-setting user preferences. The Eclipse Launcher by Yatta, which extends Oomph, might also be interesting to you.
Yes if your eclipse versions match up. You can do it by straight filesystem copy. If its not same then metadata may create loading issue.
Related
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.
All,
I have a 20 member dev team working on a development project.
To provide greater control we have created a workspace with necessary projects and configurations (like project preferences, set-ups etc) in IBM RAD.
The idea is to have the pre-configured project in subversion so that when the dev team members checkout the project they get a complete workspace, so that they do not have to configure setups them selves.
However the problem is everytime someone checks out the workspace IBM RAD will also edit the .metadata (and some other folders and properties file) folder that has been checked in.
Idea is the developer should not have to change anything except the source code folders or application specific files.
I think many other teams might have faced situations like this.
Can anybody provide the best practices/process/references on how this is done in development projects?
Thanks
I think svn ignore will solve your problem.
check http://svnbook.red-bean.com/en/1.1/ch07s02.html
The svn:ignore property contains a
list of file patterns which certain
Subversion operations will ignore.
Perhaps the most commonly used special
property, it works in conjunction with
the global-ignores run-time
configuration option (see the section
called “Config”) to filter unversioned
files and directories out of commands
svn status, svn add, and svn import.
You cannot stop IBM RAD from updating .metadata folder and Eclipse doesn't support splitting workspace folder as it does for the configuration folder.
The best solution would be to setup your build scripts to be able to setup your workspace based on some .zip file(s), where you've captured the required settings for the workspace. This will give the closest thing to automatic workspace setup without having to deal constantly with changed files in .svn.
I've been told that an Eclipse workspace is the equivalent of a Visual Studio solution. But I've also been told that people commonly use a single workspace for all their work. Are these apparently conflicting statements correct? If yes, how do we then create and maintain the equivalent of multiple VS solutions in Eclipse?
Secondly, in the case of VS, I check in my solution (.sln) files, too, into source control. Correspondingly, should I or should I not check in the Eclipse workspace's .metadata folder?
I don't think, the Eclipse workspace is equivalent to the VS solution. An Eclipse workspace stores a lot of meta-information about projects, their physical location (possibly in or outside of the workspace folder), etc., and even workbench settings. It is not a good idea to upload this information into source control, as it is possible that other developer uses other physical locations for the projects, etc.
There is a similar concept in Eclipse to the solutions (similar, not equivalent): Project sets. It is only a GUI option to group your projects into sets. These sets cannot be executed together, and is only visible in the Project navigator.
Another way is to create multiple workspace folders, and you can use them as an alternative to solutions. The drawback of this approach is, that if you customize the IDE (e.g. by using Preferences, or by defining source control locations), these customizations have to be made in every workspace. This issue can be handled using the Workspace Mechanic tool (I haven't tried it, but it can migrate these settings).
The main reason why it is better FOR ME to have a separate workspace for a single project is performance and lucidity. With many projects within one workspace, you'd have to close the other ones because of shared classpaths for editor assistance. Editor uses classpaths of all projects for content assist, class hierarchy lookup etc.
Eclipse anticipates that the open projects are related. And when using project managers like Maven, one maven project is usually divided into many little eclipse projects. It's simply a best practice to have a separate workspace for a project. Second reason is, that usually you'd need to import another related project to see how things are done and it would be terrible mess then having it all in one workspace.
You definitely shouldn't commit the .metadata folder into source control. You commit only the projects inside. Because you and others then will check out the project only into their own workspace. But it is a question whether you should commit the .project file, because it's personalized and eclipse version specific and things like project nature (java, spring, maven nature etc.) can anybody set up by himself. .classpath files in the project should be committed to the source control, because they specify classpaths, it would be very time consuming setting it up again.
You can either group your projects in different workspace or in a particular workspace. Non can be harmful once you manage your settings properly.
In eclipse you can create a new directory for a sub-project under the root project and add to the build path like so:
Does anyone know how Eclipse determines which projects are in a particular workspace? Is there a config file somewhere with this info? I have struggled (in vain) for several hours trying to figure this out. I'd like to be able to edit this config / check it into SVN...
I think Eclipse works much better if you manage just the individual projects in your version control system.
You can publish the set of projects that make up a workspace as a Project Set File (an XML file that can be created as Export > Team > Project Set), which you could put in your repository. This file contains the repository location for all projects, so that they can be checked out all at once.
I agree with Thilo that it is not a good idea to put the workspace metadata into your version control system.
However, in the spirit of answering the question and letting others make their own value decisions: The directory ${workspace_loc}/.metadata/.plugins/org.eclipse.core.resources/.projects should contain one directory for each project that eclipse uses to keep track of where the project is on disk and a whole bunch of other information.
What do I have to do to copy a complete workspace from one computer to another and be simply able to continue working on it on the other computer?
In general, a filesystem copy should be sufficient. If you run into problems with your projects, try removing the project from the workspace (without deleting the files) and then re-add the project, which will rebuild the metadata.
Make sure you shut down eclipse before you copy the workspace, and that the target computer has the same (or higher) eclipse version, including the same plugins.
Check that your workspace actually contains all the projects - when creating a project, it's possible to have its files situated outside the workspace.
If your projects use any external libraries installed on the system, install these on the other system in the same place (or adjust the paths).
Then, there should be no problem.
You shouldn't have any issues with a straight filesystem copy as long as your eclipse versions match up.
If they don't, the project metadata may not load correctly
You need to copy the whole folder which you select as your workspace at startup (or you once selected). All settings are included in there (even the opened files).
I use rsync for this. Works great.