Re: [xmlvm-users] OneJar and XMLVM

[Lennie De V. <len...@gm...>]

The one JAR approach is nice if you got a small project but XMLVM is
getting to a size where its not... by splitting everything into
seperate JARs make it more modular.
You can have a set of developers working on the Android-iPhone
specific libraried without inclusing the core lib or other libs.

On Fri, Sep 17, 2010 at 8:03 PM, Arno Puder <ar...@pu...> wrote:
>
> 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
>
> ------------------------------------------------------------------------------
> 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
>



-- 
Lennie De Villiers Blog: http://lenniedevilliers.blogspot.com/