[jdt-debug-dev] Re: [platform-debug-dev] New Launch Config API Feedback

[Darin_Wright@xxxxxxx]

Thanks for the feeback.

I agree that we should provide an abstract launch config tab, and an abstract Java launch config tab to ease development of new tabs. As well we will promote all the Java tabs to API such that others can re-use any of the tabs in other launch configurations, and move the JRE setting to the environment tab. I have filed the following bugs to track this work:

http://bugs.eclipse.org/bugs/show_bug.cgi?id=10847
http://bugs.eclipse.org/bugs/show_bug.cgi?id=10848
http://bugs.eclipse.org/bugs/show_bug.cgi?id=10850

The remaining problem deals with overriding default values - i.e. the JUnit launcher would like to have different default settings for perspective switching. Currently, a tab is responsible for initializing default values that pertain to it. A tab could initialize other values, but as you point out, this is dependent on tab initialization order (as a later tab cab override any previous tab's settings). I can forsee other lanuch configurations wanting to do the same sort of thing (for example, set a default working directory).

The most flexible solution that I can propose for this problem is to define an (optional) "initializer" attribute associated with a tab. If specified, it will be called to initialize attributes for a tab - when unspecified, the tab does the initialization. This would mean that we must disallow tabs to be contributed for "all" types of launch configs (as the "common tab" is). Each launch configuration would have to contribute all the tabs it requires. Feedback appreciated.

Darin

Erich_Gamma@xxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 03/06/2002 06:10 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-debug-dev] New Launch Config API Feedback

I've just converted the JUnit launch config to the new API (it didn't make
it into the build
of yesterday, sorry). I like the improvements a lot. The added life cycle
support simplifies
the client code significantly. In addition, support for headless launch
configs is
goodness as well.

Here is some feedback:
*     the JavaLaunchConfigurationTab is not API so I needed to
      duplicate it. Most of the code in JavaLaunchConfigurationTab
      isn't Java specific and would be generally useful when implementing
      launch config tabs. I'd suggest:
      *     we add an AbstractLaunchConfigurationTab that provides
            the non Java standard behaviour. Having to call setControl
            to make the base class know about the created contents
            is unhappy (I forgot to call it and had to debug why the
            page is empty). However, it is consistent with the WizardPage.

      There will several Java based launch configs (e.g. for applets,
      servlets) and providing more reusable standard behaviour
      would be appropriate. I therefore suggest:
      *     add an AbstractJavaLaunchConfigurationTab for
            Java based launch configurations.

*     I had to fully duplicate the JRE handling code. This more than
      a Java application launcher should have to copy. Moving
      the JRE to the Environment page would allow most Java launch
      configs to reuse th he code related to the JRE setting. An
alternative is that
      we provide a base tab from which clients can inherit the JRE handling
      logic.

*     For the JUnit launch config I'd like to disable the switching to the
run-time
      page by default in the launch configuration. There is no way to do
this. I can
      set the perspective attributes to null in the setDefault method
      of the main tab, but the Common tab will override it according
      to the preferences. Changing the preference to not switch
      to the debug perspective when running would also make
      sense.

*     The Environment tab class:
            org.eclipse.jdt.internal.debug.ui.launcher.JavaEnvironmentTab
      should be promoted to API, so that others can contribute it without
      having to refer to an internal class name.

I've also found some issues with the existing Java launching support and
I've filed bugs for them:
http://dev.eclipse.org/bugs/show_bug.cgi?id=10838
http://dev.eclipse.org/bugs/show_bug.cgi?id=10839

--erich


_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev