我实现了一个自定义操作,如此处所示,我有一个似乎可以工作的系统。我省略了“接触点”扩展,因为在我的情况下它是不必要的,但其余的都是一样的。
我的操作是在我的功能(instructions.install)的安装阶段执行的,但也许配置阶段也可以工作。收集阶段不起作用。
该操作在安装过程中执行,下载完成后。理想情况下它会在下载之前,但这对我来说不是一个大问题。从操作返回错误状态会取消安装。它留下了一些下载的文件,但它们没有被激活,并且可能稍后被 p2 的垃圾收集器删除。
我还设法做了一些更有趣的事情。我的操作插件对我的主插件有依赖关系(可选且非贪婪)。所以安装是这样的:
- 动作插件已下载
- 执行自定义操作
- 该操作检测我的主插件是否已经安装,如果是,它会调用它以检索许可信息。主插件必须为该操作公开一个 API。该操作还检查主插件的版本以检测 API 是否存在。
- 该操作现在可以决定是继续还是取消安装。它甚至可以使用 Display#syncExec 与用户交互(这是 checkTrust 阶段的代码所做的,所以我认为它是安全的)。如果需要,该操作还可以检测安装是否是无头的。
一些陷阱:
- 动作本身必须是版本化的。它是您在 plugin.xml 和 p2.inf 文件中声明的版本,它与插件的版本不同。我只是将 1.0.0 替换为与我的插件相同的版本。这样,动作插件的最新版本总是在执行之前被下载。这很棒,因为现在许可规则的任何问题更改都可以在操作插件中实现。
- Actions API 在 Eclipse 3.5 和 3.6 之间发生了变化。我可能会放弃对 3.5 的支持,因为它已经很老了。
- Actions 插件可能应该被签名。我的情况就是这样。该系统对我来说似乎太强大了,因为只需将 Eclipse 指向一个更新站点就可以让它执行下载的代码。
我仍然需要测试它如何与不同版本的 Eclipse 和其他 IDE 一起工作。我在 3.6 中看到了一个奇怪的(非阻塞)错误。然而,结果是有希望的,而且看起来该系统可能确实有效。