Hi Devs,
I want to pick up an older thread.
Back at the time of the discussion, we didn't know that Batik makes so many
problems.
For the next release (5.1.0), I thought about making the maven dependencies to
Batik and XmlSec optional.
In Gradle this is realized via features/capabilities.
So here are the decision to be made:
a) make Batik optional? (Batik is used for rendering slideshows, WMF, EMF to
SVG and SVG processing in XSLF)
b) make XmlSec/BouncyCastle optional? (those are used for signing and extended
crypto)
c) provide gradle metadata additional to maven POMs?
Please also read below for the consequences of making a dependency optional -
this still applies.
Andi
On 06.11.20 11:31, Yegor Kozlov wrote:
Hi Andi,
Got you. I thought you were going to change module-infos only and catch
ClassNotFound at module load time instead of runtime, so that if a module
is missing POI would load anyway with a sensible message . Pardon my JPMS
ignorance, I thought it was possible.
Option (a) makes sense (though I myself prefer slim distros). It will make
it easier to use POI with JPMS which is good. Changing the scope in Maven
will add a few MBs to the application size, but it shouldn't be a problem
either.
As to OSGi packaging, I'd still like to keep these dependencies optional as
they are now.
Regards,
Yegor
On Thu, Nov 5, 2020 at 11:21 PM Andreas Beeker <kiwiwi...@apache.org> wrote:
Yegor, either I don't understand you or one of us two is wrong ...
From a user perspective bouncycastle & co will still be optional
but it will be us who catch ClassNotFoundException.
It's fine then to make them mandatory.
This is a contradiction in my view.
So we can either pick ..
a)
- if classpath loading is used, we need to catch ClassNotFoundExceptions
- our dependencies are mandatory
- we use "requires" in module-info
- we change all "provided" maven dependencies to "compile"
- the user don't need to add "--add-modules"
- if one required dependency is not on the users module path - for
whatever reason - the application can't be launched
b)
- if classpath loading is used, we need to catch ClassNotFoundExceptions
- our dependencies are optional (current state)
- we use "requires static" in module-info
- we keep the "provided" maven dependencies
- the user needs to add "--add-modules"
- if an optional dependency (which isn't added via add-modules) is not on
the classpath - the ClassNotFound is catched (see above)
- with the Service Loader pattern, the loading of a scratchpad format will
simply fail, if the corresponding scratchpad jar is not requested
Disclaimer: although I've tested several configurations while setting up
the multi-module build,
I'm by far (not?) an expert in JPMS - so maybe my conclusions above are
wrong ...
Andi
On 05.11.20 09:37, Yegor Kozlov wrote:
I see. From a user perspective bouncycastle & co will still be
optional
but it will be us who catch ClassNotFoundException.
It's fine then to make them mandatory.
On Thu, Nov 5, 2020 at 12:37 AM Andreas Beeker <kiwiwi...@apache.org>
wrote:
I haven't tested it, but I assume we can catch the
ClassNotFoundException.
So when defined as "requires static" the POI module would load and
throw a
ClassNotFound/NotDefined when the code is reached.
When we define it as "requires" and the dependencies aren't on the
module
path, I think it will crash in the beginning.
---------------------------------------------------------------------
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
