Java 将静态代码分析从单独的进程移动到Eclipse插件

我目前正在为静态代码分析器开发一个Eclipse插件。分析器是用Java编写的。到目前为止，Eclipse插件使用自己的启动配置类型以及

JavaLaunchDelegate

的子类在单独的过程中执行代码分析器。Eclipse插件和代码分析器通过新进程的stdin和stdout进行通信。非常难看

现在，我们的目标是清理这个。首先，我们将代码分析器转换为不仅是一个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：简单的启动配置现在对我们很好，所以我们坚持使用它。

我们现在使用一个简单的

LaunchConfigurationDelegate

，我们从自己的启动配置类型声明中删除了

sourceLocatorId

和

sourcePathComputerId

属性。这确实防止了不必要的过程。此外，我们没有注意到调试中的任何问题。因此，我认为问题1和2被解决了。关于问题3和4：简单的启动配置现在对我们来说很好，所以我们坚持使用它