[izpack-devel] Updating to latest version of NanoXML

[Elmar Grom]

Ari,

since I was a bit sloppy with the terms I used, I just want to clarify that
I was always writing about the javax.xml.* package.

Using this will not add any code to IzPack, since the user has that code
already on their machine. Instead IzPack will come with less baggage,
because NanoXML can be removed.

	Elmar

-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Ari
Voutilainen
Sent: Monday, January 08, 2007 12:17 PM
To: izpack-devel at lists.berlios.de
Subject: Re: [izpack-devel] Updating to latest version of NanoXML


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

_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel