40

我很快将检查一个新 Java 项目的第一次提交。我使用 Eclipse Ganymede 和一堆插件使事情变得更容易一些。

以前我参与过整个Eclipse项目签入的项目。签出后获取项目设置非常方便。然而，这种方法仍然不是没有问题：

  • 我强烈怀疑某些 Eclipse 配置文件会在没有用户交互的情况下发生更改（从我使用 Eclipse Europa 时开始），当需要进行提交时，它们会显示为已更改（因为它们已更改，但不是交互的）。
  • 每个开发机器都有独特的设置，以及项目中所有开发人员的全局设置。把这些分开很难。
  • 有时，如果 Eclipse 版本与其他版本不同，Eclipse 会生气并弄乱项目配置。另一种情况是它更改格式以便更新，如果提交会破坏其他人的配置。

对于这个特定项目，我还有另一个理由不提交项目文件：

  • 可能会有更喜欢 NetBeans 的开发人员，他们稍后会加入该项目。然而，他们不会在未来几个月内加入。

你如何组织这个？你在版本控制中检查了什么，你在外面保留了什么？在这种情况下，您认为最佳做法是什么？

4

12 回答 12

21

至少您应该签入.project和.classpath文件。如果您团队中的任何人在其中硬编码外部 JAR 位置，.classpath您应该将他们靠在墙上并射击他们。我使用 Maven 来管理我的依赖项，但如果您不使用 maven，您应该使用一致的命名约定为您的外部 JAR 创建用户库。

之后，您需要逐个插件地考虑事情。例如，我使用 Spring，所以我总是签入.springBeans，同样对于 CheckStyle，我总是签入.checkstyle项目。

当涉及到文件夹中的配置时，它会变得有点棘手，.settings但如果我更改项目的默认设置并希望它们与团队的其他成员共享，我通常会签入以下内容：

  • .settings/org.eclipse.jdt.ui.prefs - 它包含导入排序的设置
  • .settings/org.eclipse.jdt.core.prefs - 它包含编译器版本的设置

一般来说，我没有注意到 Ganymede 在我修改项目首选项的情况下修改文件。

于 2009-01-15T00:49:54.290 回答
9

我建议使用maven，这样整个生命周期就在任何 IDE 之外。您可以在命令行上轻松地使用它创建一个 eclipse 项目，如果它不是 eclipse，您可以使用任何您想要的东西。它有它的怪癖，但在依赖关系和构建管理方面消除了很多苦涩。

于 2009-01-15T12:10:49.220 回答
7

在我们的世界中，我们签入整个 Eclipse 项目和整个并行但独立的 Netbeans 项目。我们这样做的动机完全集中在“当我进行结帐时，我希望之后立即进行功能配置”。这意味着我们必须做一些工作：

  1. 为每个主要 IDE 创建可运行的配置（人们喜欢他们喜欢的东西）。这包括主类、工作目录、VM 参数等。
  2. 为我们所有的相关场景创建有用的启动脚本。
  3. 创建不会导致结帐时间过长的编辑数据集（这是一个大项目）。

当我们的新员工能够检查从 Subversion 到 Eclipse 的项目并立即运行具有（小）真实数据集的功能系统时，这种理念值得现金（或至少更有价值的劳动时间）或打扰他。

跟进：这种“让新人的生活更轻松”的理念在他更换 IDE 后再次得到了回报（他在使用 Eclipse 很长时间后决定尝试 Netbeans，并决定坚持一段时间）。根本不需要任何配置，他只是在 Eclipse 指向的同一目录中打开了 Netbeans 项目。经过的切换时间：大约 60 秒。

于 2009-01-15T23:11:07.920 回答
6

我只检查过人类完成的事情，其他任何生成的东西（无论是否自动）都应该很容易再次生成并且容易改变（如你所说）。唯一的例外是生成的文件很难（需要大量人工干预；））才能正确处理。像这样的事情真的应该以某种方式自动化。

于 2009-01-15T00:23:51.207 回答
4

尝试将您的项目移植到像 maven 这样的构建系统。它拥有在您使用的每台机器上获得相同项目体验所需的一切。

一切都有插件。就像 eclipse 插件一样。您只需键入“mvn eclipse:eclipse”，插件就会生成整个准备就绪的 eclipse 项目。

回答你的问题。在开发周期中的任何时候都不要签入项目未使用的文件。这意味着像 eclipse 属性等元数据文件永远不应该在 SCM 中签入。

于 2009-02-05T16:48:44.253 回答
3

我喜欢签入 .project、.classpath 和类似文件，前提是它们在任何 Eclipse 用户的机器上都是相同的。（无论如何，使用其他 IDE 的人应该能够签出和构建您的项目，但这个问题与是否签入 Eclipse-only 文件是正交的。）

如果从事该项目的不同用户想要更改或调整他们的 .project 或 .classpath 或其他文件，我建议您不要将它们签入源代码控制。从长远来看，它只会引起头痛。

于 2009-01-15T00:36:49.340 回答
1

我使用具有 XML 项目文件的 IntelliJ。我不检查这些，因为它们经常更改并且在需要时很容易重新创建。

我不签入 JAR 文件。我将它们保存在一个单独的存储库中，即 Maven 2。

我不检查 WAR 或 JAR 或 javadocs 或任何其他可以生成的东西。

我确实检查了 SQL 和脚本以及 Java 源代码和 XML 配置。

于 2009-01-15T00:21:17.623 回答
1

由于您提到的缺点，我建议版本控制系统忽略实际的项目文件。

如果项目设置中有足够一致的信息可以从可访问中受益，请将其复制到 Eclipse 不视为特殊的位置，并且您可以在结帐时使用它（然后复制回来到 Eclipse 会注意的地方）。将实际项目文件与受控制的文件分开很有可能会导致同步丢失，所以我只建议在设置可用时有明显的好处（或者你确信你会能够使它们保持同步）

于 2009-01-15T00:33:47.240 回答
1

在我们的案例中，我们过去常常签入项目文件（.project 和 .classpath），以使所有开发人员都可以轻松创建他们的项目工作区。公共首选项文件和团队项目集也位于源代码控制中，因此创建工作区就像导入首选项和导入团队项目集一样简单。这工作得很好，但确实依赖于每个人都有一个一致的环境，任何自定义都必须在创建基本工作区之后应用。

大多数情况下，我们仍然这样做，但现在使用 Maven，因此依赖管理当然是通过 Maven 来处理的。为避免信息冲突，.project 和 .classpath 已从源代码管理中删除，现在在我们导入团队项目集之前通过 maven 目标生成。这很容易支持不同的环境，因为您只需要脚本来根据 Maven 配置生成 IDE 特定部分。

PS-不过，为了便于维护，我更喜欢让每个人都使用相同的环境。其他任何事情都不可避免地成为某人的全职维护工作。

于 2009-01-15T15:39:41.607 回答
1

Netbeans 6.5 有一个改进的 Eclipse 项目导入，它应该将来自 Netbeans 的更改同步回 Eclipse：http ://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-EclipseProjectImportAndSynchronization

于 2009-01-19T15:01:58.237 回答
0

不。仅签入项目的源代码。

于 2009-01-15T00:22:53.487 回答
0

作为回应：

“每台开发机器都有独特的设置，以及项目中所有开发人员的全局设置。将这些分开很难。”

Eclipse 提供了多种方法来保持本地设置的可管理性：Java 类路径变量（Java > 构建路径 > 类路径变量）是一种，“链接资源”（常规 > 工作区 > 链接资源）是另一种http://help.eclipse.org /stable/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-13.htm在我看来，创建一个说明在构建/运行项目之前要设置哪些设置的自述文件效果很好。

现在如何确保您的持续构建系统理解对 eclipse 设置所做的更改，这是另一个问题......（我有一个单独的 build.xml 用于 ant，我手动保持最新）

于 2009-01-15T10:45:06.867 回答