views:

89

answers:

2

I usually have multiple copies of a project, for example: a copy of the trunk and another of the last release branch. To cleanly separate my project files from Eclipse, they are checked out from Subversion in a directory outside the Eclipse workspace.

I want to make the project easily importable to Eclipse and followed instructions from multiple answers.

The problem is that my .launch files have the project name hardcoded. When a new project is imported, the launch files will display in the Run Configurations menu just if the project has exactly the same name of the exported one. This forbids me to have two version of the same project.

It looks like the only way to do it is to have the .launch and .project files generated from an Ant task, but I don't see anyone using this solution. Maybe I should have multiple workspaces and the project always with the same name.

What's the best way to do it?

Edit: I'm marking VonC as the answer, but don't miss the comments.

+2  A: 

My recommendation is to tie the workspace to the checkout location, and then you can use the launch configurations for the relevant projects in Subversion.

My directory structure looks like this:

{checkout root}
   |
   +code
   |
   -workspace

In your case, that would mean a workspace for the trunk, and any other branch/tag you check out. I also keep all my projects outside the workspace. The workspace directory in Subversion is empty; I just recursively add the project reference(s) to the workspace from the sibling tree. It also helps if you export your Eclipse settings, as you can then re-import them into each new workspace.

I derived this approach from a pair of IBM and Rational white papers for using Eclipse with Rational ClearCase. This should work unless you need to have multiple versions of the same project open in the same workspace.

mlschechter
+2  A: 

Remember that the .launch configuration files don't have to be in your workspace.
They can be in your <project>/.settings as I mentioned in the answer you refer to.

That means you cannot import in your eclipse workspace two versions of the same project.
You need separate workspaces (not versioned themselves), each one referring to a project in a different path.
Each path represents different working trees (like different working directories for Subversion).


The OP adds:

The project must have the same name, but the project checkout dir can have any name.

To make the launch file work, you have to reference any file using the variable ${workspace_loc:ProjectName}.
Java files can be referenced using a path like: '/ProjectName/src/package/MyFile.java'
This way, it is easier to use any tool to interact with the subversion repository.

I want to make life easier for who uses Eclipse, but I don't want to force anyone to use it.

VonC
Thanks for the answer. I've been testing this approach. My conclusion is that if I checkout the project from a tool outside eclipse (e.g. subversion command line), the checkout dir *must* have exactly the Eclipse project name. Is it right?
neves
@neves: that is quite possible, all my directories are named after the eclipse project name.
VonC
@VonC: Well, I can make it somewhat relative. The project *must* have the same name, but the project checkout dir can have any name. To make the launch file work, you have to reference any file using the variable ${workspace_loc:ProjectName}. Java files can be referenced using a path like: ''/ProjectName/src/package/MyFile.java''This way, it is easier to use any tool to interact with the subversion repository. I want to make life easier for who uses Eclipse, but I don't want to force anyone to use it.
neves
@neves: excellent points. I have included them in my answer.
VonC