Command argument syntax and completion support for 3rd party command line tools
| Project: | JNode Shell |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Support in the current shell command framework for attaching command argument syntax to 3rd party command line tools would be very useful.
The idea is that when we include an external command line based tool and repackage it as a JNode plugin then when we add an alias for the main class of the tool, as we can do it already, we should be able to add a syntax descrption too for that alias. This should make the external tool completely compatible with JNode command and shell environment which means that the help command should display the standard help information for the alias, the code command argument completion should be fully functional when using the alias and the command should also work with the built-in stream redirection and piping features available in the shell.
With this feature we could immediately enhance the usability and JNode integration of the more than a dozen standard Java tools that we reuse from OpenJDK like javac, jar, keytool etc. without writting JNode speciffic wrapper commands for those tools.
This feature could be used just as well for any external tool that we may adopt in the future.
For such external tools a mechanism would be useful where we could avoid the need for repackaging the tool and still have the desired functionality.
A possible solution is that the provider of the tool would include in the jar distribution an xml file with the necessar JNode speciffic information. The JNode classloader could detect it and connect the tool to our command infrastructure.
- Login to post comments
#1
Pretty please, adopt one command-line completion standard for all commands. 3rd party commands should follow the standard set by 1st party commands. For seemless integration, there should be no runtime distinction between 1st party and 3rd party commands. It might be possible to adopt a standard based upon an XML document as a resource. Let's say that we wrap our command class in a jar, we put an XML document inside the jar, the XML document provides command-line syntax.
(Or, let's say that we wrap our command class in a jar, and like OSGi, we put additional properties in the jar manifest (META-INF/MANIFEST.MF file). Like OSGi, a custom class might be useful to provide a start-up for the jar, such as registering an alias. Why not just adopt OSGi? This has been suggested before in topic 749.)
With an XML document as a resource, it enables us to tightly couple the class file and the command-line syntax. It enables JNode to be open ended at runtime.
Add a jar to classpath and immediately start using its commands.
Of course, this reminds me of previous discussions about a JNode Software Development Kit, a set of tools and procedures for building a JNode-compatible 3rd party command--without running JNode. In other words, a JNode SDK enables 3rd parties to develop and distribute 3rd party commands.
A command-line syntax verifier tool, for example, would enable a 3rd party to verify an XML document before it goes into the jar.
#2
Why not just adopt OSGi?
Assuming that this is a good idea ... we would need some person to volunteer to make it happen. Would you be prepared to volunteer gchii?
#3
For a moment, let's say we'd like to include an Equinox option with JNode. As you know, Equinox is the OSGi engine that runs Eclipse. Imagine including it without modifying its source code. Imagine including the official redistributed jar. Is the license for Equinox compatible with the license for JNode?
For a moment, let's say that the license is not a problem. Equinox creates a general class loader and one class loader for each OSGi bundle. A command line approach might be easy to implement. A JNode-specific interface is needed to invoke a command line from within an OSGi bundle. With this interface, a 3rd party bundle invokes the alias command when it is started to register its commands. Give a bundle the ability to invoke a command line and it acts like an agent.
Of course, we'll need a JNode command to start Equinox. Hmm...
#4
See comment #2
#5
I cannot find a definitive answer to your question about licensing. EPL is not compatible with GPL, but JNode is LGPL. But anyway, it is not obvious that an off-the-shelf implementation of OSGi plugin APIs would meet JNode's needs. Are you volunteering to investigate this?
#6
One standard for all commands would be impossible unless all commands were to use public static void main(String[] args) as their only entry point.
This topic was about completion for commands which were not written to the JNode API. How do you expect JNode to convince Sun to change the main entry point so that all other commands can comply with the JNode API?
#7
Here is what I am thinking.
I assume that alias and command-line completion are closely related.
I assume that command-line completion is going to continue as an XML document.
I assume that we can use an XML document as a resource.
I assume that we can modify class path dynamically from the command line.
I assume that command-line completion is dynamic because class path is dynamic.
I assume that "foreign" applications running on JNode are not distributed with JNode-compatible command-line completion. JNode might provide one or more compatibility XML documents for foreign applications.
Supposed we choose standard name for all alias + command-line completion resources, such as
When adding a jar to classpath, read the XML document as a resource. The XML document should associate an alias with a command class and provide command-line completion. When removing a jar from classpath, remove the alias and its command-line completion.
THEREFORE, we can create one alias + command-line completion standard for all kinds of command classes, both static main(String[] args) and JNode API.