Here is the features I have added to jnode sources in the past and I am now thinking to remove :

Support for vmware disks : it's based on 'Virtual Disk Format 1.0' specifications (from VMWare)
The implementation is here : distr/src/apps/org/jnode/apps/vmware/disk
The tests are here : distr/src/test/org/jnode/apps/vmware/disk/test
I started to write that when I wanted to embed some files inside a jar and inside the iso to use them inside jnode.
It's an incomplete and some parts of the specifications wasn't clear. Now, I strongly prefer to use KVM and I have the application packager (among other ways), I don't see any need to continue that work (if there is some interest ouside of jnode, it might become its own project, independently of JNode).

jar file system : the intent was also to build a JNode filesystem on top of a jar file. Like for above, I don't feel the need to continue that thing.
The incomplete implementation is here : fs/src/fs/org/jnode/fs/jarfs

It was brought to my attention that some of the changes made to the command classes have made the readability of their code harder for those that use IDEs. Those are as follows...

1) The argument declaration/instantiation. I separated the two because most of them were so obscenely long that it required 2-3 lines in order to stay within the 120 char limit. For someone like me that can't use an IDE, this looks like a complete mess. But i guess the IDE does something to clean it up? or is it simply a tolerance that java developers have for breaking their lines over multiple lines?

2) The 'help' strings that are embedded into all the commands, which will in all likelihood be removed once my i18n framework is stable. Therefore, instead of writing their names in CAPS, i wrote them in lower-case. I suppose it really doesn't matter either way as private static final String is likely unique enough. This was simply for the use of a string stripping script i have that was mass remove all the strings from the commands once the i18n framework took over the job.

Let's say that a.html and b.html should be concatinated into a single HTML document. As you may know, the cat command creates an invalid document with an <html> tag in the middle of the document.

cat a.html b.html > c.html

How would you do this with POSIX-style commands? I don't know. I want something like head and tail, but to skip the first/last line of text. Does grep work? Assuming an HTML document has fewer than 9999 lines...

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.

Recently I've started using Maven 2 for a lot of my "day job" projects. My initial reason for doing this was to keep some dependency management issues from getting out of hand, and to move away from the need to checkin lots of large 3rd-party JARs. But I'm starting to see the benefit of Maven in other areas as well.

So, I'm wondering if Maven (or Ivy) might be the long term answer to our dependency issues. For example, the "big classlib JAR file" issue might be addressed by creating a POM for classlib and uploading the JARs to a Maven repository. Versioning of classlib could be taken care of using POM versioning. (The same approach could be applied to the builder tools JAR ... if we created one.)