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 

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

Reply via email to