一个团队的 Java 多 IDE 支持答案

【问题标题】：Multi-IDE Support in Java for one Team一个团队的 Java 多 IDE 支持
【发布时间】：2010-09-17 11:01:57
【问题描述】：

让程序员团队在同一个项目中使用 Netbeans、Eclipse 和 IntelliJ 的最佳方式是什么，从而消除“哪个 IDE 更好”的问题。

哪些文件应该或不应该签入源代码控制？

【问题讨论】：

标签： java eclipse ide netbeans intellij-idea

【解决方案1】：

我认为最好的方法是让构建过程独立于 IDE。这意味着您的项目不应依赖任何特定于 IDE 的文件来构建，而应使用外部构建系统，例如 Apache Maven、Apache Ant，甚至是制作或自定义脚本。大多数流行的 Java IDE 直接或通过插件支持 Maven。

如果您不想使用外部构建系统，您至少应该使项目尽可能易于设置（即通过为共享库和其他依赖项设置标准文件夹）。过去，当我在具有多个 IDE 的团队中工作时，我花费最多的时间来解决依赖关系，因为构建项目的先决条件会随着时间的推移而发生变化。在最坏的情况下，您甚至可能最终导致开发人员不费心从版本控制存储库中获取最新版本，因为他们认为设置新项目非常麻烦。

如果您的项目有许多库依赖项，我认为在版本控制存储库中以二进制形式提供这些是一个好主意。这样人们就不必为了构建单个项目而解决依赖关系的所有依赖关系等等。但是，这确实要求您有人负责在“官方”二进制文件发生更改时使其保持最新。（这与 Maven 存储库使用的理念几乎相同，但即使不使用 Maven，也可以手动应用这些原则。）

【讨论】：

【解决方案2】：

嗯，这是一个非常自我回答的问题。

不签入源代码控制的文件是与 IDE 本身有关的文件。

让开发人员生成这些文件。

如果你使用Maven，它可以为你生成Eclipse的.project和.classpath等文件。一般来说，Eclipse 非常易于使用基本文件结构（使用新的Java Project 选项）。

我认为 Maven 也支持 Netbeans，但不确定 IntelliJ。

Maven 的网站是maven.apache.org。

【讨论】：

要基于此答案，请参阅maven.apache.org/plugins/index.html。靠近底部的是 Eclipse 和 IDEA 的插件。您将项目加载到您的 IDE 中（没有 IDE 特定文件，然后让插件为您创建这些文件。
NetBeans 插件在这里：mojo.codehaus.org/plugins.html ... 为什么我不能为此获得代表？
生成的项目不包括您可能拥有的任何插件的项目特定配置设置。引导时没什么大不了的，但刷新时请记住。
最好“让开发人员生成这些文件”，但要确保它们是从同一来源生成的。如果不使用 maven，你绝对应该使用类似的机制来组织依赖等。
这基本上就是我们目前在做的，十个开发者3个IDE的一套pom文件。 Intellij 的 maven 支持非常好。

【解决方案3】：

对于每个拥有多个开发人员的 IDE，请签入所有支持文件。为什么要在每张桌子上重新发明轮子。

我已经使用许多不同的 IDE 完成此操作，但我还没有看到文件名冲突。

事实上，即使只有一个开发人员使用特定的 IDE，对支持文件进行版本控制对他/她来说是有利的，原因与您在开发环境中对其他文件进行版本控制的原因相同：history、diffing、cmets等。

【讨论】：

重要的是让开发人员的生活更轻松，这样他们就可以加入项目并立即启动和运行
确实，还有一个原因。在我当前的项目中，我估计每个可以将 IDE 配置与源代码一起提取的新开发人员可以节省十几个小时。

【解决方案4】：

对于 Eclipse，这将是 .classpath 和 .project 文件。

我的团队使用 Maven，不鼓励开发人员签入特定于 Eclipse 的文件。因为它们可以从 Maven 生成，所以这些文件是多余的。

此外，检查特定于项目的文件似乎可以节省时间，但由于不同开发人员的工作站存在差异，这通常会很痛苦，导致浪费时间解决特定于 IDE 的文件中的冲突。解决这个问题的唯一方法是强制每个人都以相同的方式设置他们的环境，这违背了与 IDE 无关的方法。

【讨论】：

【解决方案5】：

在同一个项目团队中使用多个工具集时有很多注意事项。例如，我的团队有使用 IntelliJ 的 Java 开发人员和使用 eclipse 的大多数前端（JSP/CSS/HTML）开发人员。我们正在将 Eclipse 用户迁移到 IntelliJ，因为我们开发的一些 IntelliJ 插件为我们的环境提供了扩展支持。我们不会为多个平台开发插件，因此我们将全面标准化 IntelliJ。

在具体文件方面，我可以和 IntelliJ 交谈。我们已经签入了 .ipr 文件和 .iml 文件。不要签入 .iws 文件。如果您也有 Eclipse 用户，请将您的 IntelliJ 项目配置为在 .classpath 文件中读取/存储依赖信息并将其提交到您的 VCS。

【讨论】：

【解决方案6】：

我们有意支持来自同一个 SVN 存储库的多个 IDE。我们的想法是，我们希望确保，如果有新人加入团队或有人必须开始在新机器上工作，我们希望他们能够检查代码库，将其导入 IDE 并立即开始工作-可以配置。

这对开发人员而言意味着他们不应提交对 IDE 文件的更改。其他所有内容（例如 src、test、lib 等）都成为我们通常每天更新和提交的集合。

附带的好处是我们已经完全消除了这里的 IDE 战争：Netbeans 和 Eclipse 人生活在完美的和谐中（斜眼看着 IntelliJ 人，但是嘿...... ;-)。

【讨论】：

【解决方案7】：

有关此主题的更多 cmets 和答案，请参阅this question (How do you handle different Java IDEs and svn?)

【讨论】：

【解决方案8】：

我们重命名 IDE 文件以使用额外的扩展名 .deletethis 或类似名称进行签入。当一个新人签出项目时，他们只需剥离额外的扩展名就可以了。这样，当人们调整他们的环境时，我们可以避免与项目文件的源代码控制冲突。而且您不必担心教育新开发人员不要签入这些文件。

【讨论】：

【解决方案9】：

通常，我认为这是一个坏主意。我不确定这是一种什么样的环境（也许是开源的？），但支持多个 IDE 真的很糟糕。如果这是不可避免的，我会推荐的一件事是在 ant 脚本中标准化您的构建。如果您有大量依赖项，这可能是在所有平台上获得可预测构建的最简单方法。

如果其中一个 IDE 恰好是 RAD（基于 eclipse），则存在一个名为 .settings 的完整文件夹，您不希望将其包含在 SCM 中。

【讨论】：

使用多个IDE有什么问题？如果你没有做任何特定于 IDE 的事情（比如使用 Eclipse 的 GUI 编辑器），那么它会正常工作。