DefaultCommandInvoker cannot cope with new-style syntax

The DefaultCommandInvoker ends up invoking commands via the command classes "static void main(String[])" entry point method. If that command class is a AbstractCommand that has been converted to use the new syntax mechanism, the command's execute method won't see any arguments from the command line.

Most if not all AbstractCommand subclasses now have a "main" entry point that does simply does this:

"new XxxCommand().execute(args)"

where the "execute(String[])" method simply delegates to the XxxCommand's real execute method:

"execute(new CommandLine(args), System.in, System.out, System.err)"

In the old syntax mechanism, the real execute method makes the call to parse the CommandLine using the command's static Help.INFO object. And everything is fine.

In the new syntax mechanism, command parsing needs to have happened before the real execute method is called. This not currently happening. As a result, commands with new-style syntax are effectively being run without any arguments.

Here's the problem. In order to do new style command parsing, the "execute(String[])" method would need the name of the alias in order to lookup the alias's Syntax. But the alias name is not available at this point.

I suppose the DefaultCommandInvoker could "smuggle" the alias name to the "execute(String[])" method via a thread local variable. Another possibility would be to recode the invoker to use the (preferred) "execute(CommandLine, ...)" entry point insteat of the "static void main(String[])" entry point.

However, I'm proposing that we treat the DefaultCommandInvoker class as deprecated, and not try to fix its behavior. I will change the "execute(String[])" method to throw an exception if it detects that the command class is using the new-style syntax mechanisms.