poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Beeker <kiwiwi...@apache.org>
Subject Jigsaw / multi module / dependencies
Date Tue, 05 May 2020 10:44:26 GMT

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?


[1] https://blog.codefx.org/tools/multi-release-jars-multiple-java-versions/
[2] https://blog.codefx.org/java/module-system-optional-dependencies/

View raw message