Eclipse：是否有一种简单的方法来协调“已安装的 JRE”跨团队？
我有一个由大约 10 个不同的 Eclipse 项目组成的应用程序。有些项目必须使用 Java 5 构建，其他项目必须使用 Java 6 构建。我将这两个 JDK 分别注册为 Eclipse 的“已安装的 JRE”列表中的“jdk5”和“jdk6”。
适当的 JRE 位于每个项目的构建类路径上，这反映在 .classpath 文件中。然而，我团队中的其他成员在他们的计算机上对这些 JRE 使用不同的符号名称。此外，.classpath 文件也会被签入源代码管理。因此，人们需要对其 .classpath 文件进行本地更改才能进行构建。
我的本能是为已安装的 JRE 列表选择命名约定，并要求所有团队成员遵守它。然而，这只会使设立新开发人员的过程变得复杂。真的，我只想说“用 Java 5 构建这个项目”和“用 Java 6 构建那个项目”。我不关心它们安装在哪里，也不关心它们的符号名称是什么。 Eclipse支持这种配置吗？
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 say "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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
执行环境是您想要的（首选项 -> Java -> 安装的 JRE -> 执行环境）。您可以更改项目的类路径以使用与特定 Java 版本相对应的 JRE 系统库，例如“J2SE-1.5”或“JavaSE-1.6”。然后，Eclipse 会将已安装的 JRE 分类到这些类别中，并在构建项目时使用适当的类别。
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.
老实说，我使用maven（maven-compiler-plugin 和profiles）来完成这个任务。
使用像 maven（或 ant 等）这样的系统可以极大地帮助我们解决开发人员之间的类路径/环境/操作系统差异问题。
Honestly, I use the maven (maven-compiler-plugin and profiles) for exactly this.
Using a system like maven (or ant, etc) helps us tremendously with classpath/environment/os-disparities problems across developers.
您可以在“首选项”->“Java”->“编译器”中配置项目特定的编译器设置。但是，这仅允许您设置合规性级别，而不能选择特定的 JDK。但也许这已经足以满足您的目的了？
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?
如果您正在同步项目文件，Eclipse 会在项目构建路径配置的“库”选项卡中维护当前的 JDK。只要每个人都安装了相同的 JDK 并将其加载到 Eclipse 中，这种情况就会很好地延续下去。
在可能的情况下，我仍然推荐 Quotidian 建议的 Maven 解决方案，但只要每个开发人员工作站设置相同，我就手动取得了相当大的成功。如果您的开发人员运行不同的操作系统，这可能会让您陷入困境，因为它可能会在 Linux 系统上查找“C:\Program Files\java”，或在 wndows 上查找“/user/lib/jvm/”，而这两者都不是会存在。
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.
如果您不得不将 .classpath 文件检查到源代码管理中，那么我鼓励您按照您的想法让所有开发人员在同一位置安装他们的 JDK（或者使用指向地点）。我认为对于同一团队的开发人员来说，拥有非常相似的环境设置会更容易，而且如果通用的环境设置有详细的文档记录的话。这样，当新开发人员加入时，您可以向他们指出您的环境设置文档，并让它们快速启动和运行 - 无需浪费时间调试 JDK 安装位置的问题。
但是，如果这不是一个选项，并且您已经在使用 Maven，那么您可以考虑从源代码管理中删除 .classpath 文件。我们最近已经这样做了，我们只是让所有开发人员运行 Maven eclipse 插件来根据 pom.xml 文件中的内容生成（或更新）他们自己的 .classpath 文件。 （即 mvn eclipse:eclipse 运行该插件）。
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).