Moving static code analysis from a separate process to an Eclipse plug-in

I am currently working on an Eclipse plug-in for a static code analyzer. The analyzer is written in Java. Until now, the Eclipse plug-in used an own launch configuration type as well as a subclass of JavaLaunchDelegate to execute the code analyzer in a separate process. The Eclipse plug-in and the code analyzer communicated via stdin and stdout of the new process. It was quite ugly :-P

Now, we aim to clean this up. First, we converted the code analyzer to be not only a jar file, but also an Eclipse plug-in. Second, we replaced the stdio based communication by a proper Java interface: The code analyzer offers an API to the Eclipse plug-in. This all works fine.

However, the Eclipse plug-in still uses its own launch configuration type with its subclass of JavaLaunchDelegate to run the analyses. This means, since the code analyzer itself is now an Eclipse plug-in, the analysis is done in the same process. However, the Eclipse plug-in still launches the extra process with the code analyzer without using it.

Question

What do we still need from the old setup?

I am quite sure, we can convert the JavaLaunchDelegate to a simple LaunchConfigurationDelegate. This should prevent the Eclipse plug-in from launching the useless process.

Next, in the plugin.xml, we declare the own launch configuration type like so:

 <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>

Here, I am not sure whether we can remove the sourceLocatorId and sourcePathComputerId attributes: The launch configuration still launches Java code, but it is no longer launched in a separate process. Do these attributes make sense when they are used with a launch delegate that is not a JavaLaunchDelegate?

Finally, I don't know whether it is a good idea to still use a launch configuration at all. This is because we don't really launch an extra process, but an operation that is executed in the Eclipse process. Is it appropriate to use a launch configuration for this use case? Also, we currently use a subclass of the AbstractLaunchConfigurationTabGroup to configure the parameters of the analysis. Is there an alternative to the own launch configuration type that allows us to launch an operation in the Eclipse process and to provide parameters via a GUI for this operation?

Question Summary

1. Can we replace the JavaLaunchDelegate with a simple LaunchConfigurationDelegate?
2. Can we remove the sourceLocatorId and sourcePathComputerId attributes from the own launch configuration type declaration?
3. Is it appropriate to use a launch configuration to execute a static code analysis that runs in the Eclipse process?
4. If it is not, is there an alternative to the own launch configuration type that allows us to launch an operation in the Eclipse process and to provide parameters via a GUI for this operation?

We now use a simple LaunchConfigurationDelegate and we removed the sourceLocatorId and sourcePathComputerId attributes from the own launch configuration type declaration. This does indeed prevent the unnecessary process. Also, we did not notice any issues with the debugging. Thus, I consider question 1 and 2 as solved. Regarding question 3 and 4: The simple launch configuration now works fine for us, so we stick with it.