[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-ant-dev] Fwd: External tools todo list...

Here are Simon's thoughts on where the external tools UI was before he went 
on hiatus. Note that the "generic console" he mentions here will probably not 
be happening.

Instead, Darin and I are looking at integrating the external tools framework 
into the debug/launching framework. This would mean that external tools would 
appear in the debug view like other launches and their output would be 
available in the debug console (among other things).

- Jared

----------  Forwarded Message  ----------

Subject: External tools todo list...
Date: Wed, 18 Sep 2002 14:22:58 -0400
From: "Simon Arsenault" <Simon_Arsenault@xxxxxxx>
To: "jared-eclipse" <Jared_Burns@xxxxxxx>
Cc: "Simon Arsenault" <Simon_Arsenault@xxxxxxx>, "Nick Edgar" 
<Nick_Edgar@xxxxxxx>

Jared,

Here is a brain dump of things left to be done for external tools. Nobody 
else has really work on the external tool project. But Rodrigo does have some 
knowledge of this and may be of some help too.

Take some time to get familiar with the code and the ideas behind it. Also,
there is a couple of *Util classes and ExternalToolsPlugin have some helper
methods.

The goal before releasing to the head stream is to have no more compile
errors and have most of the previous functions in release 2.0 working
still. Also, the  package org.eclipse.ui.externaltools.internal.ui should
eventually be empty and then deleted...but that is more of a pre 2.1
release goal.

Also, as you are modifying classes in this internal.ui package, please
update the copyright notice (just look at a class in another package and
copy/paste).

   BuilderPropertyPage needs to be updated to have no compile errors. Look
   at the .view package to see how a new external tool is added and how it
   is edited. You can make use of those actions. We also need an "Add"
   button on this page. This button would show a dialog with a list of all
   the external tools that you can see in the External Tools view (again,
   look at the .view package to see the code that presents this list in the
   view). When the user selects a tool from this list, we would make a
   "copy" of it and place it as an external tools builder. These would be
   then two totally independent tools, so changing one will not affect the
   other. Thinking more about this, maybe "Add" is not such a good name for
   the button... Once the copy action is implemented (in the .view package)
   you can make use of this code. Also, once the class is ready, we should
   move it to the .internal.dialog package, we should also update the
   plugin.xml file by moving the contribution from the "old stuff" section
   to the top part of the file.
   ConfigurationDialog and EditDialog should be deleted. The only reason
   they are still there is to have access to the old code. But they have no
   purpose anymore. The ConfigurationDialog was replaced by the External
   Tools view. The EditDialog is replaced by both the external tools new
   wizard and property dialog.
   AntAction represents the "Run Ant..." menu item on a context menu for an
   .xml file. I'm still not sure what this should do. One option is to drop
   this action completely (also remove contribution in plugin.xml file).
   Another option is to have this action launch the ant external tool new
   wizard, but if so, maybe "Run Ant..." is not such a good menu name
   anymore? Third option is to have it prompt only for the target/arguments
   and then create an external tool underneath if it does not exist (this
   is what we do in release 2.0). This would kinda be like invoking the
   "Run With..." action on an Ant external tool. If we go with any of these
   options (I prefer #3) or some other one, we need to rename this class (I
   prefer RunAntAction assuming we stay with the current menu name). If we
   keep this action, once it is updated, we should create a new package
   org.eclipse.ui.externaltools.internal.ant.action in the Ant Tools
   Support source folder and move this action into it. It should not refer
   to any internal code in the External Tool Base source folder (except for
   the ToolMessages, ExternalToolsPlugin. and IHelpContextIds).
   AntLaunchWizard and AntLaunchWizardPage are used only by the AntAction
   class. If we keep this action and depending with option we go with, we
   need to move these classes to the Ant Tools Support source folder
   (probably .dialog package) or delete them. If we keep them, we can
   probably rename them too if applicable. The wizard does a bunch of work
   to launch the external tool...we should drop all that code and simply
   use the RunExternalToolAction instead. We will need to update the
   AntLaunchWizardPage to use the AntTargetsGroup instead of creating its
   own widgets. Then we can also delete the classes
   AntTargetContentProvider and AntTargetLabelProvider. (side note, what
   this is doing is very close to what the Run With... action would do from
   the UI perspective...so maybe we can reuse the same classes there when
   we implement the Run With... action later on)
   LogConsoleDocument, LogConsoleView, LogTreeContentProvider,
   LogTreeLabelProvider, and OutputStructureElement is all related to the
   current external tools console. We can leave these here for now. But
   once the generic console is ready, these 5 classes should be deleted as
   they will not be needed anymore. Also, remember to delete the entry in
   the plugin.xml file concerning the view contribution for the log console
   (see "old stuff" section at botton of file)
   ToolsPreferencePage basically only has preferences concerning the
   console. Again, once the generic log console is ready, it will have its
   own preference page, so this page will not longer be needed. Now, we
   will also need to update the plugin.xml file because the Ant external
   tool preference page is a sub-item of this page. It will need to become
   a top level preference page unless we find we have some global external
   tool preference page need.

Ok, that takes care of that internal.ui package.

Some areas where the code is not complete in the new rework:
   We have a new action called Run > External Tools > Run Last Tool  It
   should have a short cut key of Ctrl+Shift+R
   Copy & Pstes actions are not yet implemented (in the .view package)
   Rename action is not yet implemented (in the .view package). This should
   work like in the navigator view where an inline editor opens up. Also,
   you will need to add a new api to ExternalToolStorage to rename a tool
   (pass in a tool and a new name). Validate the new name will be unique.
   Then apply the change. Look also closely at the ExternalToolRegistry as
   it has some caches dependent on the tool name which will need to be
   updated also.
   The Run With... action does the exact same thing as the Run action at
   the moment. What this action should do is allow a client contributing an
   external tool type to specify either a wizard or dialog that we would
   invoke to prompt the user before running the tool. For example, a
   "program" type external tool would want to prompt for arguments. An Ant
   type external tool would want to prompt for arguments and ant targets to
   run. The restriction is this wizard/dialog can only work with the
   argument field or extra attributes. This wizard/dialog would not modify
   the tool. Instead, the Run With action would get the entered argument
   and extra attribute values entered by the user and place them in the
   DefaultRunnerContext. We'll need to update this DefaultRunnerContext.
   Right now, it has a var to hold onto the args, but for extra attributes,
   it goes to the tool directly. It should have a variable for the extra
   attributes entered by the user. So then it looks in that var first, then
   if not found, goes to the tool. Until we get this done, we should
   disable this action (or get it to show a dialog saying it is not yet
   implemented...otherwise people will not understand what it is for).
   The threads that are used by the ProgramRunner to read the input/error
   streams could be optimized. Maybe reading a few bytes at a time or until
   a CR is detected? I guess this will depend on how the generic console
   will work.
   The ProgramRunner, while waiting for the runtime.exec process to
   complete, does not check for monito cancelled. This should be changed.
   ExternalToolRegistry:from/toCommandArgs methods use the "=" as the
   key/value separator. We need to handle the case where the key or value
   has a "=" in it. Maybe by using "==" to mean a single "="?
   In AntUtil, storing run target list uses "," as the separator but does
   not handle the case where the target name contains a "," in it. Again,
   we should use ",," to mean ","?
   When you edit/create a new tool, the "Browse" button for specifying the
   location and work directory do not work. They should show a dialog. At
   the top, there would be two radio button on one line. Something like: "
   ( ) Variable  ( ) File System". If variable is selected, then
   underneath, the variable form should be shown (see
   ExternalToolVariableForm). There is an extension point for both location
   and work directory variables. Look at how the refresh scope group makes
   use of this variable form. If file system is selected, then underneath a
   widget(s) should be shown to select a file or directory. I think the
   workbench or swt has support for this. We do not want the file selection
   dialog to open here.
   On the "Options" page, the "Variables" button does not do anything at
   the moment. It should open a dialog with the variable form in it. There
   is an extension point for supplying argument variables. The new variable
   should be added at the current cursor location.
   There are some methods in the RunExternalToolAction that are not
   implemented yet (like showing the console view... by the way, the UI
   team should be looking at providing an api to show a view without it
   taking focus...there was not resolution about what to do with fast views
   that need focus in order to show themselves...talk to Eduardo about the
   status of this)
   Not all variables have been defined in the XML yet. These need to be
   added (see the IExternalToolConstants for a complete list...ignore the
   editor ones for now). Also, only some variables have a valid "Extender"
   class and "Component" class implemented so far. We need to add the rest.
   For the working set variable, we should get Knut to provide us from the
   workbench a class that we can use. Right now, there is a dialog, but it
   would be better to have a class which we could call some create* method
   with a parent composite. That way, it's embedded in the variable form.
   I've talked to Knut about this so he has an idea what I want. He is also
   reworking the ui for working set and I've asked in to consider this
   request. Check with him when you get close to working on this.

Aside from that, this project needs a great deal of testing. I've done very
little and given the amount of changes, I'm sure there are serious problem
lurking in the back somewhere ;-)

My suggestions is to do the following before releasing to head:
   Get builder property page fixed up and moved to proper package.
   Decide what to do with the Run Ant action. If unsure at the moment.
   disable the code and remove contribution from the plugin.xml
   Get ride of the ConfigurationDialog and EditDialog classes
   Update the Run With action to show a dialog saying it does not do
   anything yet

Then maybe you should start looking into the generic console. Every now and
then, you could start thinking about the rest of the work and do a bit at a
time. The Run With and Run Ant actions are the biggest and need some amount
of thinking here.

Simon :-)

-------------------------------------------------------