【问题标题】:Seeking advise for sharing Eclipse Projects寻求分享 Eclipse 项目的建议
【发布时间】:2011-10-17 11:17:24
【问题描述】:

我正在寻找有关在开发人员之间共享 Eclipse 项目的最佳实践的建议。

在我看来,每个开发人员都应该拥有自己的 Eclipse 工作区。然而,项目似乎更适合许多用户使用同一个项目,例如,如果多个用户正在处理特定组件,他们都可能需要使用该组件的项目,因为如果他们每个人都有自己的项目,他们每个人都必须设置和维护相同的项目依赖项等。看看这是否是其他人所做的,或者他们是否有理由为每个开发人员提供针对特定组件的自己的项目。

另外,如果建议共享一个项目,那么对于配置管理 Eclipse 项目的建议是什么?过去我们使用过 ClearCase,但我们现在希望改用 Git 或 SVN。在 ClearCase 世界中,经常进行签入和合并以帮助团队保持最新状态似乎是可取的。再次,我正在寻找已经经历过这种情况的人们的意见。

感谢任何建议或外部“如何”书籍或网站!

谢谢,

【问题讨论】:

    标签: eclipse configuration-management


    【解决方案1】:

    共享 Eclipse 项目不会导致任何问题。只需将 .classpath、.project 文件和 .settings 目录(以及 Eclipse 在项目根目录中生成的任何与项目相关的配置文件/目录)置于源代码控制之下。

    此外,请避免在您的项目中使用绝对路径(例如,对于外部库),因为所有开发人员不一定具有相同的设置并使用相同的位置。

    Git、SVN 或 ClearCase:没关系:都允许共享 Eclipse 文件。

    【讨论】:

      【解决方案2】:

      我们将整个 Eclipse 项目文件夹置于版本控制之下(使用 svn:ignore 表示包含已编译类的目录)。

      这使我们不仅可以共享构建配置,还可以共享启动配置(使用适当的 VM 参数)、团队认为相关的编译器警告配置,以及正在使用的编码约定的格式化程序配置。我们也可以这样设置文本文件编码。

      【讨论】:

        【解决方案3】:

        ...避免在项目中使用绝对路径

        好点子。

        我们在 ClearCase 中遇到了一些问题。我们的第三方库被放置在版本控制下的文件系统的不同部分。因此,为了避免指向库的绝对路径,我们添加了一个 ant 脚本。该脚本会将库复制到项目根目录下的视图私有目录。

        然后,我们向项目添加了一个构建器,以确保在每次清理 + 重建时首先运行脚本。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2021-11-28
          • 2011-11-14
          • 1970-01-01
          • 2013-03-13
          • 2012-04-22
          • 1970-01-01
          相关资源
          最近更新 更多