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] > >
