Bug 64411 - Provide JigSaw modules
Summary: Provide JigSaw modules
Status: RESOLVED FIXED
Alias: None
Product: POI
Classification: Unclassified
Component: POI Overall (show other bugs)
Version: 4.1.x-dev
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-05 13:24 UTC by Andreas Beeker
Modified: 2021-01-22 21:40 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Beeker 2020-05-05 13:24:09 UTC
This is a continuation of bug 62355. We should provide named modules to better support JigSaw modules.

The simple way would be to only add a manifest entry - but this is limiting the JigSaw feature. So I've decided to provide multi release modules.
Currently only the module-info class is provided, but that might change when other elements in the JDK get deprecated too.

Discussions:
http://mail-archives.apache.org/mod_mbox/poi-dev/202005.mbox/%3Cd53b113e-6677-72e1-522a-95dc5ef833a1%40apache.org%3E

http://apache-poi.1045710.n5.nabble.com/Jigsaw-multi-module-dependencies-tp5735175.html
Comment 1 Andreas Beeker 2020-05-05 13:47:10 UTC
the first patch (r1877398) contained ...
- remove dependency to jaxb:
this was only used for loading the preset shape definitions and custom geometry for slideshow. With the deprecation of jaxb in jdk 11, further dependencies would have been necessary ... providing a custom parser for the shape definitions was the light weighted solution

- add a dependency macro in build.xml

- changed the library layout
all the libraries are now in sub directories under /lib.
when using the module-path directive, java hiccups on the utility libraries (don't know which one it was), so separating the libraries after its usage in the poi modules is more clean

- add module info to xml schema jars (initial)
tbd: is the merged schema, which is released and the lite schema

- add module info to main module (initial)

- provided the schema sources in our svn tree
every now and then, we have connection problems to the ecma server and it simply doesn't make sense to download 35mb when only 200kb of schemas are necessary
Comment 2 Eugene Kortov 2020-05-27 19:50:25 UTC
After rearranging some lib folders of ooxml in https://github.com/apache/poi/commit/114a4dbd41c56e4c544836e58fae02aae6793cdf, gradle build (and therefore IDE imports) was broken. This pr https://github.com/apache/poi/pull/183 fixes the issue.
Comment 3 Andreas Beeker 2020-07-22 22:11:01 UTC
applied via r1880164
- use classpath-build for Java 8, otherwise use modulepath
- save module-info classes to source, when using Java 9+ environment
- rename example packages - otherwise package clashes occured in the tests
- move agile encryption from ooxml to main.
  remove EncryptionInfo XmlBeans and schema and use custom xml marshalling
- move ooxml test classes which reside in the same package as their tested main class
- rename base test classes to "BaseTest..." - temporarily I've used a light version of the main test classes to test scratchpad / ooxml
- build.xml - fixed the Rhino javascript errors of the dependency-macros
- DrawTextParagraph - fixed StringIndexOutOfBounds when logging set to debug level
- use JigSaw provider interface (= Java ServiceLoader), i.e. it wasn't possible (without setting everything to open), to access ooxml factory classes from main factory stub
Comment 4 Andreas Beeker 2020-08-13 21:11:38 UTC
applied via r1880839


a) provide service locator pattern to conform with JigSaw - see WorkbookFactory / -Provider on how it would look like.Although chances are that won't work with OSGi, we need that approach with JigSaw.
There are workarounds for this: http://www.basepatterns.org/java/2009/09/30/osgi-service-locator.html.

b) the above leads to service provider instances, therefore I replace static factory methods with instance methods.
Furthermore I rename all provider methods like "createXY" (createWorkbook) to "create(...)"
this is just more straight forward than e.g. ...

POIXMLExtractorFactory a; a.createExtractor(...)

i.e. I already have the extractor factory handle, why would I need to repeat that I'd like to create an extractor ...
I haven't planed to provide a generic factory interface yet, but that would make things easier later on.


c) remove main() methods in the extractor. Those look like test methods and I don't want our source verification tools to complain about poor command line handling


d) use interfaces instead of abstract classes - ONLY POI*TextExtractor
those abstract classes only add minimal logic which can be handled by default methods. on the other side I have problems with common classes like SlideShowExtractor and a new sub extractor for OOXML offering additional OOXML logic when keeping the abstract classes


e) removing a few obsolete constructs like PowerPointExtractor
Comment 5 Andreas Beeker 2020-08-14 19:09:35 UTC
applied via r1880860
- use service locator for SlideShowFactory
Comment 6 Andreas Beeker 2021-01-22 21:40:18 UTC
5.0.0 is out ... so I'm closing this

I guess we will get similar issues to this one in the near future ...:
https://stackoverflow.com/questions/65831117/module-commons-math3-not-found-using-jdeps