Question

我目前正在开发一个用于静态代码分析器的Eclipse插件。分析器是用Java编写的。到目前为止，Eclipse插件使用自己的启动配置类型以及JavaLaunchDelegate的子类来在单独的进程中执行代码分析器。 Eclipse插件和代码分析器通过新进程的stdin和stdout进行通信。这很难看:-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为此操作提供参数？

问题摘要

我们可以用简单的JavaLaunchDelegate替换LaunchConfigurationDelegate吗？
我们可以从自己的启动配置类型声明中删除sourceLocatorId和sourcePathComputerId属性吗？
使用启动配置执行在Eclipse进程中运行的静态代码分析是否合适？
如果不是，是否有替代自己的启动配置类型，允许我们在Eclipse进程中启动操作并通过GUI为此操作提供参数？

Answer 1

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

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

问题

问题摘要

1 个答案: