Let me say first that I am generally not in favor of a rip and replace strategy. It tends to be change for the sake of change, and if we can avoid it, that would be better. I know that we have issues with XMLBeans, but since we have been offered the opportunity to patch XMLBeans, maybe that would be the appropriate choice rather than replacement.
On the other hand: The current dependency is XMLBeans 2.3.0, but we could potentially bump that up to 2.6.0. I agree that it will take a lot of work to replace XMLBeans, and given we haven't identified a viable replacement, that work should be focused toward architecting a scheme to make its replacement easier. In the meantime, I don't think we can really afford to delay 4.0.0 until we have identified the replacement and completed the rearchitecting, and built the new scheme. Maybe we say that 5.0.0 will have a new plugin architecture that will decouple the XML marshaller from the API, and 6.0.0 would add new plugins for one or more additional marshallers. That is a lot of work, and would require rethinking how the whole POI project views reading and writing XML formats. There are other things to consider as well. Right now we handle the XML, and for binary formats, the binary records in line so that we can easily retain unknown parts/records/XML. But do we have to do it this way. If we used a reader/writer strategy and maintained the document in POJOs, then maybe in each POJO we could have a place to store unexpected data for writing back to the document. Maybe that would allow us to use less memory. A reader/writer strategy could make it easier to keep all access using XMLBeans or whatever XML marshaller we decide to use in the readers and writers. And we could potentially have readers for various file formats, and writers for various formats, and therefore be able to read in CSV for example, and write back out in XLSX. This decoupling would make it impossible to just go into the XML to add an additional feature, but that is currently true of the HxxF formats (not technically, but effectively due to the complexity of the HxxF formats). But it would make conversions to HTML and PDF much easier as we wouldn't have to write a converter for each format we can read, but rather a single writer for each format we wish to write. We could also conceivably support the OASIS Open Document Format this way by just adding a reader and writer for each document type. This probably goes way beyond what anyone was thinking. Anyway, I vote #1, but make sure #2 continues to work. -----Original Message----- From: pj.fanning [mailto:fannin...@yahoo.com] Sent: Monday, January 08, 2018 7:52 AM To: dev@poi.apache.org Subject: XMLBeans in 4.0.0 release Relating to https://bz.apache.org/bugzilla/show_bug.cgi?id=59268 : would it be possible to have a vote on what the XMLBeans solution should be for the 4.0.0 release? I understand the desire to replace XMLBeans altogether but I don't think we have enough developer time available to do this in the 4.0.0 time frame. 1. Keep Apache XMLBeans 2.6.0 dependency - if users run into issues with XMLBeans, they can choose to configure their own project builds to swap in https://github.com/pjfanning/xmlbeans instead. 2. Make https://github.com/pjfanning/xmlbeans the default dependency 3. Delay POI 4.0.0 release until we can get an adequate replacement for XMLBeans. -- Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
