6

您知道有关使用更新站点规则的任何文档吗？过去两年半我一直在管理我们公司的更新站点，这些是我必须解决的问题：

  • 并非所有项目都使用相同的 eclipse 版本。我们有使用 eclipse 2.1 (WSAD)、eclipse 3.0 (RAD 6)、eclipse 3.2 (RAD 7)、eclipse 3.3 和 eclipse 3.4 的项目。
  • 我们公司的更新站点大多是打包在一起的。所以我写了一些小插件（有时是片段）来打包我们公司的Checkstyle配置和当前版本的Checkstyle。
  • 我们每年发布两次新版本的变化。因此，如果我有 1 个或 4 个更新站点，这将极大地改变我必须承担的负载。

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

4

2 回答 2

4

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

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

这将使其易于部署，将事物分开，并使用户可以轻松地看到“啊，这是给我的”。

于 2008-11-28T10:03:14.140 回答
1

您可能应该使用按 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 版本的更新站点，但这正是您要避免的。

于 2008-11-28T10:07:48.733 回答