Hi Andi, What exactly is wrong with Batik? Does it pull conflicting transitive dependencies?
Both (a) and (b) make sense, but we need to ensure users get an exception with a sensible message with instructions on what/how to add on the classpath. It will also make usage of these dependencies consistent in OSGi and JPMS . Currently Batik and XmlSec are optional in OSGi but mandatory in JPMS. It makes sense to have them consistent. Do we care about existing applications running POI and Batik/XmlSec? If we change the scope then applications that render SVG using POI 5.0 will start failing. . Egor сб, 11 сент. 2021 г., 20:55 Andreas Beeker <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
