I must admit to not knowing much about JPMs and worry more about Maven POM definitions.
>From a pom perspective, generally, I think we should include all the >transitive dependencies and document how users can choose to exclude certain >dependencies that might lead to bigger deployments but may not be needed by >all users. This is just my impression that it is better to make it easy to use >POI while helping the minority of users who are concerned about deployment >size by documenting what to do. >From a JPM perspective, it feels like you need to use '--add-module' to add >extra optional modules and that it is harder to exclude stuff (I'm not aware >of there being a '--remove-module' concept). If this is the case, then maybe >we need to follow a similar line with the POM dependencies - making some >dependencies optional. Whichever way we go, it's hard to keep everyone happy. I don't see any harm in supporting gradle metadata module files in our Maven releases. On Saturday 11 September 2021, 18:55:49 IST, Andreas Beeker <[email protected]> wrote: 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
