我有一个现有的 Eclipse 插件，它作为常规 IDE 插件运行，从 GUI 接收命令并在自定义视图中返回输出。
我想添加一种能力也能够在无头模式下运行该插件，从命令行接收输入并将输出发送到某个文件。除了现有的常规执行之外，是否有某种方法可以修改现有插件以支持该执行模式，或者我是否必须创建一个新的无头插件并仅使用第一个插件中的代码？
I have an existing Eclipse plugin which run as a regular IDE plugin, receiving commands from the GUI and returning output in custom views.
I want to add an ability to also be able to run that plugin in headless mode, with the input received from the command-line and the output going to some file. Is there some way of modifying the existing plugin to support that mode of execution in addition to the existing regular execution, or do I have to create a new headless plugin and just use code from the first one?
发布评论
评论（1）
这取决于您计划如何使用此插件以及主要问题：是否存在您的 UI 依赖项不可用的情况，即是否存在没有 SWT 和 RCP 捆绑包的捆绑包配置？
没有可用的 UI
在这种情况下，您需要将插件的无头部分提取到新插件中，然后新插件将无头入口点注册到其中。插件的 UI 部分将取决于新插件，并且仅将 UI 请求委托给无头部分中的相应 API。
为了提供无头应用程序，您应该分别查看 org.eclipse.equinox.app.IApplication 接口和 org.eclipse.equinox.applications 扩展点。定义应用程序后，只需调用以下命令即可启动它：
eclipse -application; 更多信息可以在 Eclipse 帮助。
UI可用
更简单的情况。只需要指定无头入口点，一切都会像以前一样工作。
然而，我的经验表明，迟早会出现插件需要拆分的情况，并且根据其复杂性，它可能会比提前拆分带来更多麻烦。
It depends on how you plan to use this plugin and the main question: is there a case, where your UI dependencies will not be available, i.e. whether there is a bundle configuration without SWT and RCP bundles?
No UI available
In this case, you'll need to extract the headless part of your plugin into new plugin, which then registers the headless entry point to it. The UI part of the plugin will depend on the new plugin and just delegate UI requests to the appropriate API in the headless part.
In order to provide headless application, you should take a look at
org.eclipse.equinox.app.IApplicationinterface and respectivelyorg.eclipse.equinox.applicationsextension point. When you've defined the application, you launch it by simply invoking:eclipse -application <app-id> <app-param>More information can be found in Eclipse Help.
UI available
The simpler case. Only the headless entry point needs to be specified and everything will work as previously.
My experience, however, shows that sooner or later, the case arise where the plugin needs to be split and depending on its complexity it might cause more trouble than it would have been if it was split earlier.