如何管理团队的 Eclipse 插件、首选项和配置？
我团队的所有成员都使用 Eclipse。然而，每个都有不同的配置、偏好和插件。保持插件基线、代码样式和格式等首选项以及其他配置的最佳方法是什么，以便具有相似的起点但允许每个团队成员进行特定配置。
我正在寻找一种易于维护的解决方案，这意味着不会有太多文件驻留在不同位置。
All the members of my team works with Eclipse. However, each one have different configuration, preferences and plugins. What is the best way to keep a baseline of plugins, preferences such as code styling and formatting, and other configuration in order to have similar start point but to allow each team member for specific configuration.
I am looking for a solution that will be easy to maintain also, means not too many files that resides in different locations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
首选项的一个简单方法是使用
文件>导入和文件>导出，选择常规>首选项，然后选择您想要共享的首选项。对于我过去的一些团队，我们将基线首选项存储在版本控制中。A simple approach for preferences is to use
File>ImportandFile>Export, choosingGeneral>Preferences, then the preferences you want to share. For a few of my past teams, we stored the baseline preferences in version control.您应该查看Pulse。我只在独立的单用户环境中使用过它，但它似乎工作得很好。我相信通过付费版本，您可以管理整个团队的工作区首选项和设置。我可能会尝试让我的公司尽快尝试这一点。
基本上，Pulse 为 Eclipse 提供了一个中央启动板。它允许您创建由 Eclipse 安装和各种插件组成的 Eclipse 安装配置文件。从启动板中，您选择一个配置文件并安装它。这会将 Eclipse 和各种插件下载到计算机上的中央文件夹中。然后它会设置一个配置文件文件夹，以某种方式链接配置文件的指定插件。因此，当您启动时，您只能获取配置文件中的项目，无论安装了哪些其他配置文件。
You should check out Pulse. I've only used it in a standalone, single user environment, but it seems to work pretty well. I believe with the paid versions you can manage workspace preferences and settings across your group. I may try and get my company to try this out soon.
Basically, Pulse provides a central launchpad for Eclipse. It allows you to create Eclipse install profiles that consist of an Eclipse install and various plugins. From the launchpad, you select a profile and install it. This downloads Eclipse and the various plugins to a central folder on your machine. It then sets up a profile folder that somehow links the specified plugins for the profile. So when you launch, you only get the items in the profile regardless of what other profiles have installed.
我们使用“基线”方法，其中有一个由几个核心成员管理的中央版本。我们的想法是下载版本，根据需要进行配置，然后将工作区和安装打包到中央位置。此外，一些插件具有我们存储在中央位置的配置文件，然后我们指向它们的基线（模板、格式化程序文件等）。
还有商业软件可以为您完成所有这些工作，如果我能找到它，我会发布链接。
希望这有帮助。
We use a "baseline" approach where we have a central version managed by a few core members. The idea is to get the version downloaded, configured as you wish and then the workspace AND install packaged to the central location. Additionally, some plugins have config files that we store in a central location and we then point the baseline them (templates, formatter files, etc).
There is also commercial software that will do all this for you, if I can find it I'll post the link.
Hope this helps.
我问了一个类似问题，并被推荐Yoxos。还没有时间尝试，但看起来很有希望。
I asked a similar question and was recommended Yoxos. Havent had time to try it yet, but it looks promising.
我在网站上的另一个问题中找到了解决方案。
它推荐了一个名为工作区机制的插件。看起来它解决了首选项和配置问题。
我正在使用它，它看起来配置不错。但它没有提供插件的解决方案。
I found a solution in another question on the site.
It recommends a plugin called workspace mechanic. Looks like it solves the preferences and configuration issues.
I am using it and it looks good for configuration. it doesn't give a solution for plugins though.
我想最重要的部分是您正在开发的插件。我们所做的是将所有需要开发的插件的源代码放入修订控制中，然后将项目导入到新的 Eclipse 工作区而不复制它们。这可能是显而易见的。
有点棘手的是作为运行时环境一部分的插件。我们有一个特殊的项目（也在修订控制之下），其中包含这些 jar，并组织在目录中。有些来自 Eclipse，有些来自 Spring、日志记录等。还有一个目标定义文件，它定义了哪些插件构成了环境。因此，您不是针对正在开发的 Eclipse 副本进行编译和运行，而是针对定义为目标平台的一组独立插件进行编译和运行。
了解和使用目标平台会带来很大的不同，因为您使用的 IDE 的确切版本不再重要 - 所有开发人员都将链接并测试相同的代码。一个很好的副作用是，您可以控制属于产品一部分的插件子集，并且不可能通过无辜的新依赖项意外引入 17 个新插件。
不幸的是，PDE/Build 不知道目标定义，但文件格式很容易弄清楚。
最后，如果重要的话，首选项和格式等可以导出到文件并保留在修订控制中。我想标准格式规则很有用。
The most important part is the plugins that you are working on, I suppose. What we do is to put the source for all the plugins that are subject to development into revision control, then import the projects into a fresh Eclipse workspace without copying them. This is probably obvious.
A little trickier is the plugins that are part of the runtime environment. We have a special project (also under revision control) that contains those jars, organized in directories. Some are from Eclipse, some are from Spring, logging stuff etc. There also is a target definition file, that defines which of these plugins make up the environment. So you are not compiling and running against the Eclipse copy that you are developing in, but an independent set of plugins that is defined as the target platform.
Understanding and using a target platform makes a big difference, as it doesn't matter anymore what exact version of the IDE you are using - all developers will link against and test the same code. A nice side-effect is that you control the subset of plugins that are part of your product, and it is impossible to accidentally pull in 17 new plugins through an innocent new dependency.
PDE/Build unfortunately doesn't know about target definitions, but the file format is easy enough to figure out.
Finally, preferences and formatting etc can be exported to a file and stuck in revision control, if it matters. Standard formatting rules are useful, I guess.