Hi Andy, That’s great news!
I think changing the module names makes this is breaking change, so will the release containing these changes be version 5.0 or a 4.x? I think I would go for 5.0 on the assumption that module and package names will stay stable for the foreseeable future. But I think it is something that has to be done anyway to achieve compatibility with jlink, That would IMHO be a great step forward - currently I have to apply crude workarounds to get blink work with POI, and I think many are facing the same problems or just decided to not use jlink for the time being with projects using POI. Another question: AFAIK some of the dependencies used by POI are not yet modularised. As you mentioned it, I think Batik is an example (unless this has changed since I last used it). As I am quite busy with my day job, I cannot put much effort into POI at the moment, but I might find some time to create patches (and PRs) to some of the dependencies to make them modularized. Axel > Am 05.05.2020 um 12:44 schrieb Andreas Beeker <kiwiwi...@apache.org>: > > 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/ > >
