Thanks Andi, Seems like the right way to go.
I'd like to see us update to XMLBeans 4 and POI 5 if the changes mean there is a user impact. We could release XMLBeans 3 and POI 4 bug fix releases if the changes take a while to complete and test. On Tuesday 5 May 2020, 12:44:35 GMT+2, Andreas Beeker <[email protected]> wrote: Hi, I'm currently reworking our dependencies and try to provide multi module [1] jars. Currently I have the following: - multi module xml schemas - the merged and lite schema is tbd - removed the jaxb dependencies from the main module and provided my own XMLStreamReader based parser for PresetGeometries. The reason for this is, that JDK 11 dropped the JAXB support - now you have some com.sun or org.glassfish dependencies to choose from. Instead of increasing our dependencies even more, I think it makes more sense to provide some custom parser. This also renders the binding classes obsolete. I'd like to also provide a multi module XmlBeans - maybe this fixes also a problem with opening the xml schemas to all. I would mark the optional dependencies as static [2] - e.g. bouncycastle, batik ... So the next release would contain ... - new XmlBeans release - new POi jars - new ooxml-schema, ooxml-security What I'm not so sure about is the effect on the user base, when suddenly the jars are multi module and the current automatic name (e.g. "poi") is overridden by a customized one (e.g. org.apache.poi.poi). This is a change we would face anyway - even if we would go with just providing an automatic name manifest entry. What are your thoughts generally and about semantic versioning in this regards? Andi [1] https://blog.codefx.org/tools/multi-release-jars-multiple-java-versions/ [2] https://blog.codefx.org/java/module-system-optional-dependencies/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
