Proposal: Mechanism for command plug-in.

Let's say that jarsearch.jar contains a Jnode-compatible command. When we add jarsearch.jar to our classpath, we must also add an alias to our alias list. And then, we can invoke the jarsearch command.

Here is a proposed mechanism for automatically adding a command alias. We add a resource to jarsearch.jar.

In a resource called META-INF/command/jarsearch.xml, we write:

<?xml version="1.0"?>
<command>
  <classname>org.gchii.demo.JarSearchCommand</classname>
  <helptext>
jarsearch command
  syntax: jarsearch [options] directory
  -package        - searches for a package by name
  -class          - searches for a class by name
  -R, --recursive - searches directory recursively
  directory       - starts search in a directory
  </helptext>
  <manual>
jarsearch command
Example
  jarsearch -class org.jnode.command.CdCommand .
  searches for
  </manual>
</command>

Thus, by adding jarsearch.jar to our classpath, we can invoke the jarsearch command. Also, the XML document might contains helpful information about the jarsearch command, display-able by a command such as help jarsearch and man jarsearch.

Interesting idea.

[I fixed the broken HTML in your posting to make it readable.]

This is an interesting idea. It is at odds with the way that we currently specify command syntaxes in XML in the plugin descriptors. However, the syntax loader could easily be adapted to read the syntax from a class path resource.

I think that we should try to unify this idea with the current plugin mechanisms; i.e. some convention for embedding the JNode plugin descriptor XML files into a plugin's JAR file.

It also relates to the requirement to be able to provide command documentation in multiple languages that can turn into online help, online manual pages, web pages and so on.