Skeleton commands

The topic was brought up before that, instead of creating wrapper command classes around apps that did their own arg parsing via 'main', classic java style, it would be better if there was a means to simply define the command within the xml descriptor, with no actual command.

==== UPDATE ====
This does not affect the Command class, how it work, or any program that is implemented via the Command interface provide in the shell project. This is simply a means to providing an ArgumentBundle, which is one of the key components required to enable the error handling, completion and help subsystems of the shell/cli interface, for classic java applications. This is to side-step the need for creating a wrapper command class + xml descriptor for each and every class java application.
==== /UPDATE ====

For a first go at this, i want to keep it simple, and I'll make a couple of assumptions.
1) The arguments and associated bundle will need to be instantiated and registered.
2) A command class will _not_ need to be instantiated.

If either of this assumptions is misfounded, then this idea probably will not work as i think it will.

Instead of the command class, we would introduce an extension point that took command definitions. Each command node would map to the 'class' defined in the alias extension point. The child nodes of a command node would be its arguments. Those arguments would take parameters that add any necessary flags or other options that the particular constructor defines. Now this is likely to be the tricky part. It would be fine if the constructor arguments are primitives/Strings, but if a constructor were to take a more complex Object (which i dont think any do at the moment), then this probably would not work. Cases like this may be limited, and could simply fallback on the command wrapper.

==== UPDATE ====
The example below has been updated to show the actual implementation that became of this. Instead of a new extension point, we added a sibling node type, called argument-bundle, that contains a list of argument constructor specifications. These constructor specs are cached in the syntax manager, and at command execution time, get instantiated and collected into an ArgumentBundle for parsing/completing of command lines.
==== /UPDATE ====

To give a clearer picture of what this would look like, lets use Jawk as an example.

<argument-bundle alias="awk">
    <typedefs>
        <typedef name="StringArgument" value="org.jnode.shell.syntax.StringArgument"/>
        <typedef name="FileArgument"   value="org.jnode.shell.syntax.FileArgument"/>
        <typedef name="FlagArgument"   value="org.jnode.shell.syntax.FlagArgument"/>
    </typedefs>
    <argument label="vars" type="StringArgument">
        <param type="flags" value="MULTIPLE"/>
    </argument>
    <argument label="script" type="FileArgument">
        <param type="flags" value="EXISTING"/>
    </argument>
    <argument label="files" type="FileArgument">
        <param type="flags" value="MULTIPLE,EXISTING"/>
    </argument>
    <argument label="compile-dir" type="FileArgument">
        <param type="flags" value="EXISTING"/>
    </argument>
    <argument label="interm-file"  type="FileArgument">
        <param type="flags" value="NONEXISTENT"/>
    </argument>
    <argument label="field-sep"    type="StringArgument"/>
    <argument label="program"      type="StringArgument"/>
    <argument label="interm-out"   type="FlagArgument"/>
    <argument label="compile"      type="FlagArgument"/>
    <argument label="compile-exec" type="FlagArgument"/>
    <argument label="dump-interm"  type="FlagArgument"/>
    <argument label="dump-ast"     type="FlagArgument"/>
    <argument label="xfuncs"       type="FlagArgument"/>
    <argument label="xtypes"       type="FlagArgument"/>
    <argument label="sort-arrays"  type="FlagArgument"/>
    <argument label="no-fmt-trap"  type="FlagArgument"/>
</argument-bundle>

Instead of having the alias manager lookup the class for that alias, it would look up the command descriptor, create an argument bundle, and register the defined arguments. I still have yet to dive into particular details, but this is the idea i've had so far. If it doesn't seem to far off track, i'll look deeper into what would actually be needed to make it happen.

==== UPDATE ====
This actually wound up having no affect on the alias manager. Everything still works the same in that regard.
==== /UPDATE ====