You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Andreas Beeker <ki...@apache.org> on 2021/09/11 17:55:44 UTC
Re: Optional dependencies and JPMS?
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 <ki...@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 <ki...@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-unsubscribe@poi.apache.org
>> For additional commands, e-mail: dev-help@poi.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Optional dependencies and JPMS?
Posted by PJ Fanning <fa...@yahoo.com.INVALID>.
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 <ki...@apache.org> 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 <ki...@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 <ki...@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-unsubscribe@poi.apache.org
>> For additional commands, e-mail: dev-help@poi.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Optional dependencies and JPMS?
Posted by Andreas Beeker <ki...@apache.org>.
Hi Devs,
> Yegor: What exactly is wrong with Batik? Does it pull conflicting transitive dependencies?
technically: https://issues.apache.org/jira/browse/BATIK-1260
organizational: same as POI - too few people to have frequent releases
> Yegor: we need to ensure users get an exception with a sensible message with instructions on what/how to add on the classpath.
If the dependency is required, JPMS will check at the program start and quits if it isn't there.
If it's optional (requires static), we probably can use reflection to check for the classes.
My preferred way in the long run would be more/specialized POI modules.
When one is using Gradle capabilities, you have the problem that the features are mutual exclusive.
So I've defined a "signing", "render" and "rendersign" feature.
This would be unnecessary with dedicated render and signing modules.
We had discussions on this point also several times, which resulted in no change.
Basically we would weigh between confusing users with new modules vs. users not reading a FAQ entry, which explains on how to use the components (e.g. how to exclude or include dependencies).
> Yegor: Do we care about existing applications running POI and Batik/XmlSec?
I think the answer is not so simple:
do we care about existing applications which are now need to exclude modules after the upgrade?
e.g. https://stackoverflow.com/questions/67789203
do we care about people complaining, that we/I change the (part of the) API with each release?
> PJ: we should include all the transitive dependencies and document how users can choose to exclude certain dependencies
My idea was to work with mavens optional dependencies. The dependency will be marked as optional, if the dependency is part of Gradle feature/capability. So if a user looks at the pom, they might get the idea what to include.
> PJ: it feels like you need to use '--add-module'
I have to correct myself, it's enough to add the module in the module-info.
Similar to the maven pom, the expectation would be, that the user looks in the module-info of the corresponding POI jar.
If you don't mind, I would commit my excludes now and wait for your feedback before the release.
Andi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Optional dependencies and JPMS?
Posted by Yegor Kozlov <ye...@gmail.com>.
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 <ki...@apache.org>
> 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 <ki...@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 <ki...@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-unsubscribe@poi.apache.org
> >> For additional commands, e-mail: dev-help@poi.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>