Community
Participate
Working Groups
I want to use external tool configurations for launching Java applications on remote targets. The steps to copy and launch an application on a specific device will be defined by external tool configurations. I suppose there is no time to come up with a structural way to use tool configurations in contexts like this. However, if I could override classes instead of cloning them this would already be an improvement To configure the external tools in another context, I need to clone the ConfigurationDialog. I could instead override the class if: - a protected method would be used in createDialogArea() to assign the tools ArrayList, and - a protected method would be used in okPressed() to save the tools. I would like to use loadExternalTools() and saveExternalTools() of the ExternalToolsRegistry. These could be rewritten to take a Reader and a Writer as argument. I need to add variable definitions like debug-port. To do this, I have to clone two classes: EditDialog and DefaultRunnerContext. In my clone of EditDialog, I changed VariableSelectionDialog.createDialogArea() and VariableSelectionDialog.okPressed(). I propose to make method hookButtonActions() use a Factory which creates the dialog classes. This factory can then be overridden to return subclasses of these dialogs. In my clone of DefaultRunnerContext, I changed private method expandVariable. I would like this method to be protected.
We are in the middle of our second test/fix pass and are focussing on critical problems only. We do not have time to consider API issues, unfortunately (even if they are kept internal). If you want to make the changes and submit them, I'll try to get them in, but at this stage all changes need to be approved by two component owners.
The plan for release 2.0 is for External Tools to have not publish any public API. There is not enough time now to properly expose the correct API - once it is exposed, we cannot change it anymore. Cloning is probably the better solution for now (even if we did make the changes you requested, they would change in the next release when we expose an API). What you could do to help us out is to provide us with more information about how you want to use the tools configuration plug-in. One option is to provide extension points (that way the Ant support could use this instead of being hard coded in). Also, if you would like to participate in this, please let us know. Defer until after release 2.0 for consideration when exposing an API to external tools.
The new external tool support will provide an extension point to supply new "types" of external tools (by default we supply program and ant types). Also, there is an extension point to supply new variables for the argument field. Would that be enough for you needs? Note: new external tool work is not yet released to the head stream and won't for a while yet.
I think this would be enough for our plans.
External tools are now launch configs. You can define a new type of external tool by defining a new type of launch configuration, with a category attribute of "org.eclipse.ui.externaltools".
marking as verified.
