[izpack-devel] Updating to latest version of NanoXML

Elmar Grom elmar at grom.net
Tue Jan 9 18:33:23 CET 2007

Hi Klaus,

as I had mentioned before, I am willing to contribute a chunk of code that I
am using for several years to work with javax.xml.*.

You can have a look at it and see how well it would fit into IzPack. I am
not sure how well it represents NanoXML calls, so some massaging might be
necessary to make insertion easier. In general it makes working with
javax.xml a snap. Most problems collapse into a single line call to one of
the XMLHelper classes.



-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Bartz, Klaus
Sent: Tuesday, January 09, 2007 12:14 AM
To: izpack-devel at lists.berlios.de
Subject: Re: [izpack-devel] Updating to latest version of NanoXML

Hi all,
will be nice if we change to an xml parser which is included in
the VM. I have played a little bit with javax.xml.*. For me it seems
so that with a flat wrapper the changes in IzPack have not to be
to big.
To declare a leadtime has the chance to define the used api (if a
wrapper will be used) and discuss it.
In my installations NanoXML is not used only in the common base of
IzPack else in all my custom code which needs a configuration via an
xml file. I will do the needed changes there because I am certain
that it is the right way.
If we find no api for a common wrapper I will do it for my own code.

We should see that a change creates an incompatibility for all users
which have custom configuration files. This has to be communicated
with big letter at a good seeing place.

May be we can create a todo list or roadmap for the next but one



>-----Original Message-----
>From: izpack-devel-bounces at lists.berlios.de
>[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Julien Ponge
>Sent: Tuesday, January 09, 2007 8:20 AM
>To: elmar at grom.net; izpack-devel at lists.berlios.de
>Subject: Re: [izpack-devel] Updating to latest version of NanoXML
>Hi guys,
>I would add that we can simplify things by combining DOM + XPath,
>which avoids many boilerplate nested loops to retrieve data. I am in
>favor or the javax.xml.* solution rather than using JDom (or Dom4j
>which I like very much). As Elmar said, the reason is that it wouldn't
>add bytes to the installers while JDom would, even if it is an
>appealing library.
>I suggest that we put this item for 3.11.0.
>izpack-devel mailing list
>izpack-devel at lists.berlios.de
izpack-devel mailing list
izpack-devel at lists.berlios.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XMLHelper.java
Type: application/octet-stream
Size: 15740 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/izpack-devel/attachments/20070109/2ecf9331/attachment.obj 

More information about the izpack-devel mailing list