Optional dependencies and JPMS?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Optional dependencies and JPMS?

kiwiwings
Hi,

we have a number of optional dependencies (bouncycastle, xmlsec, batik and now pdfbox and others) which can be easily not/included on the classpath.

On the modulepath, one need to use the --add-modules argument to activate those modules even when they were declared as "requires static" in the module-info.

I would like to make the optional dependencies mandatory.

Pro:
+ users don't need to fiddle around with the maven dependencies and don't need to add add-modules arguments.

Neutral:
* drive space is not really an issue nowadays

Con:
- there might be side effects with existing dependencies

What is your opinion?


Andi


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional dependencies and JPMS?

Yegor Kozlov-4
Does it mean that the JPMS modules will not load if these new dependencies
are missing?

Won't it be an acceptance killer?


Yegor


ср, 4 нояб. 2020 г., 22:40 Andreas Beeker <[hidden email]>:

> Hi,
>
> we have a number of optional dependencies (bouncycastle, xmlsec, batik and
> now pdfbox and others) which can be easily not/included on the classpath.
>
> On the modulepath, one need to use the --add-modules argument to activate
> those modules even when they were declared as "requires static" in the
> module-info.
>
> I would like to make the optional dependencies mandatory.
>
> Pro:
> + users don't need to fiddle around with the maven dependencies and don't
> need to add add-modules arguments.
>
> Neutral:
> * drive space is not really an issue nowadays
>
> Con:
> - there might be side effects with existing dependencies
>
> What is your opinion?
>
>
> Andi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Optional dependencies and JPMS?

kiwiwings
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.

Andi


On 04.11.20 21:11, Yegor Kozlov wrote:

> Does it mean that the JPMS modules will not load if these new dependencies
> are missing?
>
> Won't it be an acceptance killer?
>
>
> Yegor
>
>
> ср, 4 нояб. 2020 г., 22:40 Andreas Beeker <[hidden email]>:
>
>> Hi,
>>
>> we have a number of optional dependencies (bouncycastle, xmlsec, batik and
>> now pdfbox and others) which can be easily not/included on the classpath.
>>
>> On the modulepath, one need to use the --add-modules argument to activate
>> those modules even when they were declared as "requires static" in the
>> module-info.
>>
>> I would like to make the optional dependencies mandatory.
>>
>> Pro:
>> + users don't need to fiddle around with the maven dependencies and don't
>> need to add add-modules arguments.
>>
>> Neutral:
>> * drive space is not really an issue nowadays
>>
>> Con:
>> - there might be side effects with existing dependencies
>>
>> What is your opinion?
>>
>>
>> Andi
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional dependencies and JPMS?

Yegor Kozlov-4
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 <[hidden email]> 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.
>
> Andi
>
>
> On 04.11.20 21:11, Yegor Kozlov wrote:
> > Does it mean that the JPMS modules will not load if these new
> dependencies
> > are missing?
> >
> > Won't it be an acceptance killer?
> >
> >
> > Yegor
> >
> >
> > ср, 4 нояб. 2020 г., 22:40 Andreas Beeker <[hidden email]>:
> >
> >> Hi,
> >>
> >> we have a number of optional dependencies (bouncycastle, xmlsec, batik
> and
> >> now pdfbox and others) which can be easily not/included on the
> classpath.
> >>
> >> On the modulepath, one need to use the --add-modules argument to
> activate
> >> those modules even when they were declared as "requires static" in the
> >> module-info.
> >>
> >> I would like to make the optional dependencies mandatory.
> >>
> >> Pro:
> >> + users don't need to fiddle around with the maven dependencies and
> don't
> >> need to add add-modules arguments.
> >>
> >> Neutral:
> >> * drive space is not really an issue nowadays
> >>
> >> Con:
> >> - there might be side effects with existing dependencies
> >>
> >> What is your opinion?
> >>
> >>
> >> Andi
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Optional dependencies and JPMS?

kiwiwings
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Optional dependencies and JPMS?

Yegor Kozlov-4
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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>