IzPack
  1. IzPack
  2. IZPACK-764

Improve XML handling - JAXB, XStream

    Details

    • Type: Wish Wish
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 6.0
    • Component/s: Compiler, Installer
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Parsing XML documents in IzPack is currently incomplete. Even though the XML syntax is well-formatted, there are not recognized bad element or attribute names, thus using the IXmlElement is error-prone especially for typos. Parsing the installation descriptor (install.xml) and several XML resources could be migrated to a different approach.

      Best choices might be:

      • JAXB
        Integrated to Java SE 6 and OpenJDK 6.
      • XStream
        Requires additional dependencies.

      There is a good comparison available for both: How Does JAXB Compare to XStream?

        Activity

        Hide
        Julien Ponge added a comment -

        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?

        Show
        Julien Ponge added a comment - 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?
        Hide
        Julien Ponge added a comment -

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

        Show
        Julien Ponge added a comment - I forgot to specify that the JDK 6+ come with a pull parser, which is easier to handle than SAX / DOM.
        Hide
        Rene Krell added a comment -

        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

        Show
        Rene Krell added a comment - 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
        Hide
        Rene Krell added a comment -

        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.

        Show
        Rene Krell added a comment - 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.
        Hide
        Julien Ponge added a comment -

        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!

        Show
        Julien Ponge added a comment - 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!
        Hide
        Daniel Abson added a comment -

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

        Show
        Daniel Abson added a comment - There's some XStream parsing in the master git branch (see IZPACK-791 ). Was that supposed to be committed to the master repo?
        Hide
        Rene Krell added a comment -

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

        Show
        Rene Krell added a comment - This is just a recommendation, there hasn't been done anything with this officially, as far as I know.

          People

          • Assignee:
            Unassigned
            Reporter:
            Rene Krell
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: