Wanted: JNode Emulator
Submitted by gchii on Thu, 08/14/2008 - 14:17.
Let's say that I really want to write and test commands for JNode--without actually running JNode. I need a JNode Emulator.
I start JNode Emulator with Apache Ant.
<path id="taskdef.cp">
<fileset dir="lib">
<include name="jnode-emulator.jar"/>
</fileset>
</path>
<taskdef name="jnode-emulator" classname="JNodeEmulatorAntTask" classpathref="taskdef.cp"/>
<jnode-emulator init="false" stdin="myscript.txt">
<argument value="shell"/>
</jnode-emulator>
I start JNode Emulator on Linux.
java -jar jnode-emulator.jar
For the sake of simplicity, let's say that JNode Emulator only runs commands with a text-based interface.
An AWT frame might be displayed. I type 'echo Hello, World!' in the prompt field and press the Run button. The emulator creates a command object and executes it, displaying the output in a text area. 'Hello, World!' is displayed.
Now, let's say that JNode Emulator is a plug-in for Eclipse. With the JNode Emulator view displayed, I type 'echo Hello, World!' in the prompt field and press the Run button. 'Hello, World!' is displayed in the JNode Emulator view.
A JNode command can be rigerously tested outside of JNode first, and should be.
- Login to post comments
JNodeEmulatorAntTask
The proposed JNodeEmulatorAntTask should enable an Ant script to invoke a JNode-compatible command. When used for the first time, the emulator task must initialize the jnode runtime environment. A minimum runtime environment should be enough to run basic commands, like ps, pwd, cd, mkdir, rmdir, rm, zip, unzip, md5sum, tar, gzip, gunzip, diff, patch, xargs, grep.
Fixed Emu
I made several fixes to Emu to make it start up and do a coupld of basic things. A lot more could be done to enable the developemnt and improvement of many shell related and other JNode services on the JDK making use of the Java platform debugger and other tools.
You can start up the ShellEmu running the following command in the main directory of the JNode sourcetree:
java -cp distr/build/classes/:core/build/classes:shell/build/classes/:gui/build/classes/:core/lib/log4j-1.2.8.jar org.jnode.emu.ShellEmu
Steve, could you please take a look at it and try to make it more usable. It's primarily the kind of things you are usually working on which could be greatly improved by this.
Clarification
Thank you.
I would like to simplify the command line from this
to this
Let's put a manifest inside jnode-emulator.jar. The Main-Class in the manifest should be org.jnode.emu.ShellEmu.
Let's create a command line tool for "load"ing extra jars. A jar is loaded by adding its classes to a classloader, processing its JNode-compatible descriptors, adding arbitrary commands to the alias list. A jar is unloaded by removing its classloader, undo-ing its descriptors, removing its commands from the alias list.
We just need a wrapper script
If the aim of the emulator is to test JNode commands, then you don't want to be rebuilding a jar file on each sandbox build cycle. The obvious answer would be to write a little wrapper script to run "java" with the right classpath and entry point class.
(Actually, I just run ShellEmu within Eclipse ...)
The latest version of ShellEmu configures commands (more or less) in the native JNode way. It figures finds out command alias names and syntaxes using the JNode plugin descriptors, and loads the classes via the classpath. It works well enough for now.
If we changed JNode so that all commands are self-contained JARs, we should do the same in the Emu world. But (AFAIK) we haven't decided to move to self-contained JARs. And I can see both advantages and disadvantages in doing that.
The primary goal is running on JNode
I'm not sure if we should go very far on this road where Eclipse plugin and support for dynamically loading and unloading jars etc. are created.
Let's don't lose from sight the primary goal which is running the commands under JNode. However if you think you need all that extra stuff for creating commands then you might try to create it. In general terms is better to avoid extra complexities if possible.
it's hard to do that outside of JNode ...
... and it can even be impossible for some commands.
In the past, I created a fake environment for running some disk partitionning/file system related JUnit tests outside of JNode and it's not easy.
Fabien
my blog : en français, in english or both
The Emu
If I recall there is a class in the codebase somewhere called "Emu" that is a possible starting point. I think Levente wrote it. It might be worth seeing if we can update and enhance it, both as a limited JNode command test tool. It could also double as a tool for running JNode commands on a classic JVM ... it is the same thing really.
But Fabien is correct that it would be far too much work to get the JNode services (file systems, devices, etc) working outside of JNode. So a significant subset of JNode commands would not be runnable, or would behave differently due to "environmental issues".