Re: [xmlvm-users] OneJar and XMLVM

[Jeff P. <jcp...@ro...>]

Maybe something like a .zip or .tar of jars will give a feel of the best of
both approaches.  One file so no accidental mis-matched use, but still
separate when used.

Yes, a .jar is already a .zip, but OS'es do special things when the
extension is .zip.  I believe OSX expands such file automatically when
downloaded & Windows shows as a directory in explorer.



On 9/17/10 3:25 AM, "Panayotis Katsaloulis" <pan...@pa...> wrote:

> 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 :)
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users