Re: [xmlvm-users] OneJar and XMLVM

[Arno P. <ar...@pu...>]

fact is that we will soon add quite a bit more to the OneJar. The source 
code of the Boehm GC and (more importantly) the cross-compiled version 
of the OpenJDK. Especially the latter will increase the size of the 
OneJar significantly.

In principle I like the OneJar approach for its simplicity: everything 
is bundled in one jar. However, we should make sure that the 
jar-inside-jar for huge files does not have any significant performance 
impact. If that should be the case, we definitely need to abandon the 
OneJar approach.

Anyone else want to chip in?

Arno


On 9/17/10 10:21 AM, Panayotis Katsaloulis wrote:
> On 17 Σεπ 2010, at 7:20 μ.μ., Joshua Melcon wrote:
>
>> Panayotis,
>>
>> The one jar distribution has a single big advantage:  It has a known, working, consistent set of files/code/classes that an provably work together.  If we wanted to I could test it and say here, it works, use it.   It is a much more difficult process (and usually combinatorially impossible) to do that with every version of every library that someone might attempt to run XMLVM against.
>
> I agree with that.
> As I said in the looong message, we can really have for our own use a "private" lib folder with all recommended lbrary versions - and leave compatibility chaos to the system packages.
> What I don't like is to have embedded OpenJDK (and much more) inside the JAR, which needed to be double-unzipped every time.
> What I am proposing actually is what every other project is doing: go from a monolithic to a modular system - even if the modules are "private", and "independent" from the "system libraries" of the same name.
>
>
>> Size: In 1992 I downloaded 12 megs over a 14400 baud modem.  It took most of the day.  These days I can download 200 mb during a coffee break.  Its just not that much of an issue.
>
> Size, probably not. But speed is. And it is here every time you compile a program. Don't tell me you haven't experienced it?
>
>> Complication time packaging time for xmlvm.jar: meaningless for users, only XMLVM dev types do that.  XMLVM run time might be a consideration, though in my experience it is fast enough that it doesn't feel like a bottle neck in my work flow.
>
> See above ;)
>
>
> ------------------------------------------------------------------------------
> 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