将静态代码分析从单独的进程转移到 Eclipse 插件
Moving static code analysis from a separate process to an Eclipse plug-in
我目前正在为静态代码分析器开发 Eclipse 插件。分析器写在Java中。到目前为止,Eclipse 插件使用自己的启动配置类型以及 JavaLaunchDelegate
的子类在单独的进程中执行代码分析器。 Eclipse 插件和代码分析器通过新进程的标准输入和标准输出进行通信。太丑了:-P
现在,我们的目标是清理它。首先,我们将代码分析器转换为不仅是一个jar 文件,而且是一个Eclipse 插件。其次,我们用适当的 Java 接口替换了基于 stdio 的通信:代码分析器为 Eclipse 插件提供了一个 API。这一切都很好。
但是,Eclipse 插件仍然使用它自己的启动配置类型及其 JavaLaunchDelegate
的子类来 运行 分析。这意味着,由于代码分析器本身现在是一个 Eclipse 插件,因此分析是在同一进程中完成的。然而,Eclipse 插件仍然使用代码分析器启动额外的进程而不使用它。
问题
我们还需要从旧设置中得到什么?
我很确定,我们可以将 JavaLaunchDelegate
转换为简单的 LaunchConfigurationDelegate
。这应该可以防止 Eclipse 插件启动无用的进程。
接下来,在plugin.xml
中,我们像这样声明自己的启动配置类型:
<extension
point="org.eclipse.debug.core.launchConfigurationTypes">
<launchConfigurationType
delegate="com.example.LaunchDelegate"
id="com.example.launch.config"
modes="run,debug"
name="Launch"
sourceLocatorId="org.eclipse.jdt.launching.sourceLocator.JavaSourceLookupDirector"
sourcePathComputerId="org.eclipse.jdt.launching.sourceLookup.javaSourcePathComputer">
</launchConfigurationType>
</extension>
这里,我不确定是否可以去掉sourceLocatorId
和sourcePathComputerId
属性:启动配置仍然启动Java代码,但不再单独启动过程。当这些属性与不是 JavaLaunchDelegate
的启动委托一起使用时是否有意义?
最后,我完全不知道仍然使用启动配置是否是个好主意。这是因为我们并没有真正启动一个额外的进程,而是一个在Eclipse进程中执行的操作。对于这个用例使用启动配置是否合适?此外,我们目前使用 AbstractLaunchConfigurationTabGroup
的子类来配置分析的参数。是否有替代自己的启动配置类型,允许我们在 Eclipse 进程中启动操作并通过 GUI 为该操作提供参数?
问题总结
- 我们可以用简单的
LaunchConfigurationDelegate
替换 JavaLaunchDelegate
吗?
- 我们可以从自己的启动配置类型声明中删除
sourceLocatorId
和 sourcePathComputerId
属性吗?
- 使用启动配置执行 Eclipse 进程中 运行 的静态代码分析是否合适?
- 如果不是,是否有自己的启动配置类型的替代方案,允许我们在 Eclipse 进程中启动操作并通过 GUI 为该操作提供参数?
我们现在使用一个简单的 LaunchConfigurationDelegate
并且我们从自己的启动配置类型声明中删除了 sourceLocatorId
和 sourcePathComputerId
属性。这确实防止了不必要的过程。此外,我们没有注意到调试有任何问题。因此,我认为问题 1 和 2 已解决。关于问题 3 和 4:简单的启动配置现在对我们来说很好,所以我们坚持使用它。
我目前正在为静态代码分析器开发 Eclipse 插件。分析器写在Java中。到目前为止,Eclipse 插件使用自己的启动配置类型以及 JavaLaunchDelegate
的子类在单独的进程中执行代码分析器。 Eclipse 插件和代码分析器通过新进程的标准输入和标准输出进行通信。太丑了:-P
现在,我们的目标是清理它。首先,我们将代码分析器转换为不仅是一个jar 文件,而且是一个Eclipse 插件。其次,我们用适当的 Java 接口替换了基于 stdio 的通信:代码分析器为 Eclipse 插件提供了一个 API。这一切都很好。
但是,Eclipse 插件仍然使用它自己的启动配置类型及其 JavaLaunchDelegate
的子类来 运行 分析。这意味着,由于代码分析器本身现在是一个 Eclipse 插件,因此分析是在同一进程中完成的。然而,Eclipse 插件仍然使用代码分析器启动额外的进程而不使用它。
问题
我们还需要从旧设置中得到什么?
我很确定,我们可以将 JavaLaunchDelegate
转换为简单的 LaunchConfigurationDelegate
。这应该可以防止 Eclipse 插件启动无用的进程。
接下来,在plugin.xml
中,我们像这样声明自己的启动配置类型:
<extension
point="org.eclipse.debug.core.launchConfigurationTypes">
<launchConfigurationType
delegate="com.example.LaunchDelegate"
id="com.example.launch.config"
modes="run,debug"
name="Launch"
sourceLocatorId="org.eclipse.jdt.launching.sourceLocator.JavaSourceLookupDirector"
sourcePathComputerId="org.eclipse.jdt.launching.sourceLookup.javaSourcePathComputer">
</launchConfigurationType>
</extension>
这里,我不确定是否可以去掉sourceLocatorId
和sourcePathComputerId
属性:启动配置仍然启动Java代码,但不再单独启动过程。当这些属性与不是 JavaLaunchDelegate
的启动委托一起使用时是否有意义?
最后,我完全不知道仍然使用启动配置是否是个好主意。这是因为我们并没有真正启动一个额外的进程,而是一个在Eclipse进程中执行的操作。对于这个用例使用启动配置是否合适?此外,我们目前使用 AbstractLaunchConfigurationTabGroup
的子类来配置分析的参数。是否有替代自己的启动配置类型,允许我们在 Eclipse 进程中启动操作并通过 GUI 为该操作提供参数?
问题总结
- 我们可以用简单的
LaunchConfigurationDelegate
替换JavaLaunchDelegate
吗? - 我们可以从自己的启动配置类型声明中删除
sourceLocatorId
和sourcePathComputerId
属性吗? - 使用启动配置执行 Eclipse 进程中 运行 的静态代码分析是否合适?
- 如果不是,是否有自己的启动配置类型的替代方案,允许我们在 Eclipse 进程中启动操作并通过 GUI 为该操作提供参数?
我们现在使用一个简单的 LaunchConfigurationDelegate
并且我们从自己的启动配置类型声明中删除了 sourceLocatorId
和 sourcePathComputerId
属性。这确实防止了不必要的过程。此外,我们没有注意到调试有任何问题。因此,我认为问题 1 和 2 已解决。关于问题 3 和 4:简单的启动配置现在对我们来说很好,所以我们坚持使用它。