Perforce Public Knowledge Base - Eclipse vs. Perforce Workspaces
Reset Search
 

 

Article

Eclipse vs. Perforce Workspaces

« Go Back

Information

 
Problem

Eclipse and Perforce both maintain workspace environments. While it may be tempting to have them share the same location on disk, they should be kept separate. Specifically, the Eclipse workspace should not be under Perforce's control.

Solution

The Eclipse workspace maintains a .metadata folder that is localized to the machine it is running on, and therefore should not be checked into the depot. Eclipse plug-ins might write files into the Eclipse workspace for things such as temp files, data caches, and things specific to that work environment.There is no reason to have these files under Perforce control.

It is a common practice in Eclipse plug-in development to import binary projects for debugging source code when running a debug version of Eclipse. Importing binary projects always imports as a project into the Eclipse workspace. These projects should not be under Perforce control, and can even result in name collisions with source projects that are under Perforce control.

Eclipse workspaces might function differently across different versions of Eclipse. It is recommended to have a different Eclipse workspace for each version of Eclipse used. Having these workspaces under Perforce control complicates the matter.

It is important to put the .project file under Perforce control, because it allows other developers to import projects from the P4 Depots view more easily. The .project file contains the information that specifies what type of project it is (Java project, Eclipse plug-in project, C/C++ project, and so on), so checking this file into Perforce allows other developers to import the project and immediately know the type of project and how Eclipse builds it.


Keeping track of projects if they are not in the Eclipse workspace

A reference to the location of your projects that are under the Perforce workspace is maintained by Eclipse within the Eclipse workspace so that Eclipse can find them. The references are URIs maintained in .location files located beneath the .metadata folder.

The .project and .classpath files, found at the root of the project, should be maintained by Perforce. The .classpath file can have relative paths for your build environment.

<?xml version="1.0" encoding="UTF-8"?>

<classpath>

<classpathentry kind="src" path="src"/>

<classpathentry kind="con"

path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

<classpathentry kind="output" path="bin"/>

</classpath>

 

Maintaining more than one codeline or branch in your Eclipse workspace

An Eclipse workspace cannot contain projects with duplicate names. So in a simple branching scenario, for example:

//depot/main/project1
//depot/r1/project1

The two "project1" projects conflict in a single Eclipse workspace. You must create separate Eclipse workspaces to accommodate each branch.

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255