在Eclipse中使用更新站点的规则？

Question

您是否知道有关使用更新站点规则的任何文档？我已经管理了我们公司更新网站的最后两年半，这些是我必须解决的问题：

• 并非所有项目都使用相同的eclipse版本。我们的项目使用了eclipse 2.1（WSAD），eclipse 3.0（RAD 6），eclipse 3.2（RAD 7），eclipse 3.3和eclipse 3.4。
• 我们公司的更新网站主要是将各种东西打包在一起。所以我写了一些litte插件（有时是fragements）来包装，例如我们公司的Checkstyle配置以及当前版本的Checkstyle。
• 我们每年发布两次新版本的更改内容。因此，如果我有1个更新站点或4个，这将显着改变我必须承担的负担。

所以问题是：我们应该使用多少个更新站点，如果数量超过1，我如何最大限度地减少维护更新站点的工作？

Answer 1

我建议将所有内容放在一个Web服务器上，并将每个Eclipse版本的软件包部署到不同的URL：

http://your.server/eclipse-3.3/site.xml
http://your.server/eclipse-3.4/site.xml
等

这将使部署变得容易，使事情分开，这将使用户看到“啊，这对我而言”很简单。

Answer 2

您可能应该使用按eclipse版本细分的功能和类别。

|
+-WSAD-2-1 Category
|   |
|   +- Checkstyle 3.1 Feature
|   |
|   `- Team Checkstyle configuration for Checkstyle 3.1
|   
`-Eclipse-3-4 Category
    |
    +- Checkstyle 4.4 Feature
    |
    `- Tema Checkstyle configuration for Checkstyle 4.4

这可能与维护多个更新站点同构，但可以考虑：

• 坚持最低的共同点，并尽量减少错误
• 为Eclipse 3.4编写的插件无法合理地用于Eclipse 2.1。
• Eclipse版本之间的一些版本颠簸导致插件编写者的一定程度的升级痛苦（例如3.0到3.1是一个很大的跳跃）
• 同一产品的不同版本之间的配置可能不兼容。
• 同一插件的版本可能具有不同的功能集，但不适用于所有版本（例如Checkstyle 5支持Java 5，但可能无法与适用于Eclipse 2.1的Checkstyle插件一起使用）

但是，如果不可能或不希望有多个级别的类别，那么推广上面建议的类别以分离更新站点是前进的方向。

这具有部署优势，因为用户可以指向他们正在使用的IDE版本的更新站点，但这正是您要避免的。