[izpack-devel] Updating to latest version of NanoXML

[Ari Voutilainen]

Hi,

Someone has said (or asked) something like this: "Why to correct 
or change 'thing' which is working well?" It seems to me that 
updating NanoXML will correct odd behaviour and that will make 
IzPack better. Only if there are good reasons to change parser it 
could be done. Elmar stated some reasons (are they enough?). If 
change has to be done my opinion is to change VM to Java 5 and 
to jDOM. jDOM will give to IzPack more than just coding wrapper. 
Actually jDOM is some kind of wrapper to javax.xml. And jDOM 
already is at stable phase. I understand that own wrapper might 
give flexibility to change XML parser to the proper one without 
recoding IzPack. But each time when change is done someone has to 
recode some part of the wrapper in order to work together with 
new parser. And we also could ask how often we will change the 
parser.

If I had understood correct NanoXML is also small packet. jDOM
is larger. In large installations it won't be problem but in tiny 
installations someone might want to find smaller installer... 
Elmar stated also that plain DOM would be enough. That would 
ideal because there will be as much Java related code as 
possible; there would be no third party code. I myself agree 
those arguments how difficult it is to work with DOM. When I used 
jDOM after some DOM experimentation it was quite easy to handle 
XML: it was straight forward to handle elements.

And again: if there are only whishes to transfer javax.xml or do 
own wrapper, keep NanoXML. If NanoXML contains problems which 
make XML handling hard, transfer to new VM and javax.xml (and 
perhaps to jDOM).

Regards,
Ari

> Hi all,
> I remember fragile that there were some changes in
> the NanoXML code which will be used by IzPack. Therefore
> the sources are holded also in the IzPack repository.
> Is this right or not?
> If so, a simple update to the latest version will be 
> problematically.
> 
> On the other hand it is not so easy to change to DOM or so
> because there are many places where xml data will be used
> and this not only in the common area of IzPack else also
> in custom code.
> On the third hand I am sometimes playing with a registry
> editor which uses my registry stuff from IzPack. For the
> configuration I need xml, but I will not use the old NanoXML
> stuff. At this point it will be nice if IzPack uses no
> extra parser.
> On principle we can use xml support of the VM because since
> IzPack 3.9 a 1.4 VM is required. There are some problems in
> NanoXML which has made us some work in the past (e.g. support
> of wrong xml files which can be fixed by a validating parser).
> 
> What todo?? 
> I vote to use the 1.4 VM classes and create a wrapper near 
> (or identically) to the NanoXML api. 
> Who do it??
> Unfortunately I do not know..., I have problems to get the time
> for other stuff I have todo for IzPack.
> 
> Cheers
> 
> Klaus
> 
>> -----Original Message-----
>> From: izpack-devel-bounces at lists.berlios.de
>> [mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Stefan
>> Wachter
>> Sent: Monday, January 08, 2007 9:13 AM
>> To: izpack-devel at lists.berlios.de
>> Subject: Re: [izpack-devel] Updating to latest version of NanoXML
>>
>>
>> Hi all,
>>
>> some time ago there was a discussion on this list that 
>> favoured NanoXML in order to stay compatible 
>> with Java 1.3, Java 1.2, ... I think this argument is still valid.
>>
>> I did update my private IzPack version to the latested NanoXML 
>> release because it solves my original 
>> problem (the 
 character not being kept). Until now I do 
>> not experience other problems. 
>> (Admittedly I did no extensive testing, yet.)
>>
>> In addition, I think that the XML API that NanoXML provides is 
>> quite usable. In contrast to that, 
>> using DOM would be not so funny. I also doubt that using some 
>> utility classes to handle DOM is a 
>> better solution than using NanoXML.
>>
>> Therefore I still suggest to update NanoXML to the latest 
>> version. I will report any problems 
>> encountered on the list.
>>
>>
>> Cheers,
>> --Stefan
>>
>>
>> PS: A very elegant means to handle configuration data is data binding.
>>
>> _______________________________________________
>> izpack-devel mailing list
>> izpack-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/izpack-devel
>>
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/izpack-devel