[xmlvm-users] OneJar and XMLVM

[Panayotis K. <pan...@pa...>]

This is a topic I find it really important for the future of XMLVM, since I've seen that there are some development decisions which should be "updated". It has to do with the usage of OneJar, which I believe it is about time to abandon it.
I'll explain why.

First of all, and more importantly, XMLVM jar is HUGE. And it is not only huge, it is huge for NOT a good reason. In general, it is not a bad idea to "statically link" all required objects inside a file. But if this file is in the order of 30MB, I think we are going to have a lot of problems with it, in regards to (a) space - the obvious, (b) time, in order to unzip items inside an already zipped file (c) packager complexity, since for example some classes (like the iphone compatibility library or the chassis & various icons) needed to be at most one level down inside the JAR file  (d) developer complexity, such as the problems we are talking now and probably others...

But this is not all. I was in the process of adding XMLVM to the MacPorts repository, in order to "advertise" it and make it more "accessible" to the people, who would like a tool that "just works" (you know how obsessed I am with this paradigm).
Unfortunately we can't - not as long as all libraries are inside XMLVM.
All distributions love small split packages, especially if there is a well documented, supported and easily provided library for each part. No sane distribution will allow OpenJDK to be "integrated" inside XMLVM, and I couldn't agree more. 
Moreover, since (all?) libraries used in XMLVM are open source and have a rapid development, XMLVM project could benefit of the multi-jar approach. This is the reason all other projects prefer to have (even a private) lib directory and keep all jars there, instead of packaging them inside a single Jar.

Last, but not least is that multi-jar approach could speed up things. xmlvm.jar could be compiled much faster (and on demand), android compatibility Jar could be created much faster etc etc. The whole procedure could be easier and more organized. If a library changes, there is no need to compile everything from scratch. Not to mention that this approach is practically "optimized" nowadays, since all other projects follow it.

The only real benefit is that XMLVM can be distributed just by one file. But this could be the case anyhow. It can be packaged and everything will be fine. Actually things are even better: instead of saying in the documentation to use the command "java -other-jvm-parameters -jar path-of-xmlvm/xmlvm.jar -actual-xmlvm-parameters", which is known to most java developers, but it is not "pretty", by using a specialized bash script things could be as easy (and straight forward) as "xmlvm -actual-xmlvm-parameters".

... and as always, I volunteer to perform this change :)