Eclipse: Is there an easy way to coordinate "Installed JREs" across a team?

I have an application that is composed of about 10 different Eclipse projects. Some projects must be built with Java 5, and others with Java 6. I have both of these JDKs registered with Eclipse's "Installed JREs" list as "jdk5" and "jdk6", respectively.

The appropriate JRE is on each project's build class path, which is reflected in the .classpath files. However, other members on my team are using different symbolic names for these JREs on their machines. Also, the .classpath files are checked into source control. As a result, people need to make local changes to their .classpath file in order to be able to build.

My instinct is to choose a naming convention for the installed JREs list and ask all the team members to stick with it. However, this just complicates the process of setting up a new developer. Really, I just want to sa开发者_开发百科y "build this project with Java 5" and "build that project with Java 6". I don't care where they are installed, or what their symbolic name is. Does Eclipse support this kind of configuration?

Execution Environments are what you want (Preferences -> Java -> Installed JREs -> Execution Environments). You can change the classpath of your projects to use a JRE System Library that corresponds to a particular version of Java, like "J2SE-1.5" or "JavaSE-1.6". Then, Eclipse will categorize the installed JREs into those categories, and use the appropriate one when building your projects.

Honestly, I use the maven (maven-compiler-plugin and profiles) for exactly this.

<plugin>
 <artifactId>maven-compiler-plugin</artifactId>
 <configuration>
  <source>1.5</source>
  <target>1.5</target>
 </configuration>
</plugin>

Using a system like maven (or ant, etc) helps us tremendously with classpath/environment/os-disparities problems across developers.

You can configure project specific compiler settings in Preferences->Java->Compiler. However, this only allows you to set the compliance level, not choosing a particular JDK. But maybe that's already enough for your purpose?

If you are synchronizing your project files, eclipse maintains a current JDK in the Libraries tab of the projects build path configuration. This will carry over pretty well as long as everyone has the same JDK installed and loaded into eclipse.

Where possible, I'd still recommend the maven solution that Quotidian suggested, but I've had a fair amount of success manually as long as each developer workstation is set up the same. This can hang you up if you have developers running different operating systems though, as it might look for "C:\Program Files\java" on a linux system, or "/user/lib/jvm/" on wndows, neither of which would exist.

If you're stuck with having to check the .classpath fies into source control, then I'd encourage you to go with your idea of having all the devs install their JDKs in the same location (or use a common env variable name pointing to the locations). I think it's much easier for devs on the same team to have very similar environment setups, and if that common env setup is well documented. That way, as new devs come on board, you can point them to your documentation for env setup and have them up and running quickly - there should be no need to waste time debugging issues around where their JDKs are installed.

If that's not an option, though, and you're already using Maven, then you could consider removing the .classpath files from source control. We've recently done this, and we just have all the devs run the Maven eclipse plugin to generate (or update) their own .classpath files based on what's in the pom.xml file. (i.e. mvn eclipse:eclipse to run that plugin).