Improve XML handling - JAXB, XStream

Let me give some background on the IXmlElement and related API.

In the early days of IzPack there was no XML parser in Java (1.2), so we went for a tiny library called NanoXML. This is where the IXmlElement interface comes from. Because it was a simple and flexible data containers, we opted to directly use the XML DOM trees to store data. Was it good or bad? At least it was very convenient.

Later on we refactored the code base to get rid of the unmaintained NanoXML, and take advantage of the JDK built-in parser. The adherence of the NanoXML to the rest of the codebase was high though, hence IXmlElement and related class serve as an adapter.

I agree that it would be great to further refactor the thing, but I am a bit skeptical about the proposed choices. XStream is not an option as it adds further dependencies. JAXB could do the job, but this is an API that can bite you hard at times.

If you really want to go this way then I suggest that you try to develop a proposal in a dedicated Git branch, preferably pushed to your GitHub clone. We can then easily discuss with the community on pull requests.

What do you think?

I forgot to specify that the JDK 6+ come with a pull parser, which is easier to handle than SAX / DOM.

Of course, JAXB is a sign of the times. I have also been gone through the evolution from JRE 1.1. I didn't mean IXlElement is bad, it's just not up to time, and compared for instance to our business solutions hard to handle. And it was worth to mention together with the discussion about consolidating variables, where we discussed XML syntax changes.
This should be done completely separately. For IzPack this would be currently more a destabilization than vice-versa
There are many small issues which are more important at the moment towards a 5.0 release. Maybe something for 6.0 or 5.1

Regarding XStream: I could even imagine dividing XML parsing into compiler and installer.
From my point of view, on the compiler side, there can be as much dependencies as necessary in favour of a transparent code base. On the other hand, on the installer side there is no good reason for using an alternative to JAXB to make the installer as small as possible.

But JAXB seems not to be that bad. I would divide the code in clear XML data mapping objects and functionality using them. The data mapping objects could be serialized in a proper way and added to the installer, even as XML. This way the way JAXB offers XML handling without programatically changing the serialization behavior is sufficient.

My take is that if you are willing to explore this path then a branch on your github is the way to go

Good luck, it could be interesting to successfully perform those changes with no overweight on the installers!

There's some XStream parsing in the master git branch (see IZPACK-791). Was that supposed to be committed to the master repo?

This is just a recommendation, there hasn't been done anything with this officially, as far as I know.