作为我工作的一部分,我受雇为公司的开发人员安装和支持开发工具。
Eclipse 是这里很多开发人员使用的 IDE,但我并不积极支持。随着插件种类繁多和新版本的快速发布 - 我发现很难掌握并且无法(显然)支持所有内容。
我在 Eclipse 方面确实有一些经验,但作为一名开发人员 - 您认为您的工作场所在 Eclipse 方面的良好支持是什么?
团队范围的安装,带有一组标准插件。
允许用户安装新的,并建议将新的放入标准安装中,但他们应该知道这些不受支持。
您的主要开发人员还将了解这些插件的哪些配置将有助于整个团队 - 例如
安装和插件都可以预先准备好并作为一个大的 zip 文件分发,或者更灵活的方法是在内部运行您自己的更新站点。
我(除其他外)正是从事这项工作。
我想出了一个大的 zip 文件:
用于启动 Eclipse 的脚本:
这样,每当我验证一组新的稳定工具时,我的所有“开发配置”都会发展。
基本上,不需要安装/更新每个插件:只需定义您和您的同事每天实际使用的一组通用核心工具。
对于一组标准插件并保持最新状态,我使用Yoxos配置了一个配置文件。
在我的工作场所,Eclipse 是标准的开发工具,发布的项目可以使用 Eclipse 进行编译(当我们发现如果 Eclipse 尚未完成构建,Makefile 没有做任何事情时,我就在那里)。简单的解决方案是考虑开发人员的需求并为他们提供所需的基本环境。自定义插件可以由开发人员自己安装在主文件夹中,并带有“不支持”免责声明。只需安装您工作场所中大多数人需要的基本环境和最常用的插件。说: - 基本环境 JDT - 图形开发/网络开发/C++ 开发插件,或任何你需要的东西 - 一些 UML 插件,如果一个明显更好 - 一些分析器,如果你可以让它工作(我已经完成了分析) Netbeans、gprof,甚至 Oprofile,但我永远无法让它与 Eclipse 一起工作——无论如何,进行分析比在 Netbeans 中更复杂)。如果人们使用它。如果人们不这样做,则可能需要重新考虑某些事情,除非因为不需要而根本没有进行优化:-)。这是人们唯一需要支持的东西,恕我直言,其余的对我来说都是透明的。- 也许,在 Linux 上,我想要 gcj 编译版本的 Eclipse 的 RPM,如 Ubuntu 和 RedHat 提供的。除了我没有证据表明它更快,而我有证据表明 ecj(独立的 Eclipse Java 编译器)本身在使用 GCJ 时要慢得多(并且有很多原因表明这是正常的)!有些事情可能需要重新考虑,除非因为不需要而根本没有进行优化:-)。这是人们唯一需要支持的东西,恕我直言,其余的对我来说都是透明的。- 也许,在 Linux 上,我想要 gcj 编译版本的 Eclipse 的 RPM,如 Ubuntu 和 RedHat 提供的。除了我没有证据表明它更快,而我有证据表明 ecj(独立的 Eclipse Java 编译器)本身在使用 GCJ 时要慢得多(并且有很多原因表明这是正常的)!有些事情可能需要重新考虑,除非因为不需要而根本没有进行优化:-)。这是人们唯一需要支持的东西,恕我直言,其余的对我来说都是透明的。- 也许,在 Linux 上,我想要 gcj 编译版本的 Eclipse 的 RPM,如 Ubuntu 和 RedHat 提供的。除了我没有证据表明它更快,而我有证据表明 ecj(独立的 Eclipse Java 编译器)本身在使用 GCJ 时要慢得多(并且有很多原因表明这是正常的)!
关于 Eclipse 的不同版本,只要坚持一个稳定的版本就可以了。在一年左右的时间里,按照 Marcin 的建议支持更新的版本。
就我个人而言,我想要一个在单个条目中包含“标准”插件的内部更新站点。这是因为可用的 Eclipse 版本种类繁多,没有人能提前满足熟练开发人员的需求。
带有内部更新站点和安装的“标准”插件以及定义的任何源存储库(以及仔细定义的步骤)的 zip 文件的通用分发将适合大多数开发人员,而不会给您带来太多负担。