excluding transitive module

[Jochen Theodorou]

On 14.04.20 11:09, Alan Bateman wrote:
> On 14/04/2020 09:24, Jochen Theodorou wrote:
>> Hi all,
>>
>> I am wondering if there is a solution purely in the module-info for this:
>>
>> * Project requires Library1 and Library2
>> * SomeLibrary requires SharedApi
>> * OtherLibrary requires SharedApiImpl
>>
>> The problem is, that it will not compile because SharedApi and
>> SharedApiImpl implement the same packages but not the same logic. One is
>> just an API, while the other is an implementation of the API.
> This seems futile without first cleaning up the architectural issues.
>
> How does SharedApi locate the implementation?

It does not, there is no SPI. It just implements the interfaces

> Is this configurable or
> does it always assume it's in the same run-time package as itself?

actually it does not even assume somebody else may have it. So yes.

> If
> the API and implementation (or default implementation) have to be in the
> same run-time package then it leads to SharedApi and SharedApiImpl
> needing to be combined into one module, not two.

so the best way would be to change SomeLibrary to require
SharedApiImpl... which means changing the library after the fact...
which is a tad difficult

> Why is OtherLibrary requiring SharedApiImpl? This suggests that
> SharedApiImpl is more than an implementation, does it have an additional
> implementation specific API that OtherLibrary make use of?

There can be different implementations (it is just no an SPI
architecture). There is one that then builds on top of SharedAPI, but it
is not the implementation I need.

> If you decide to combine the API and default implementation into the one
> module then it will look something like this:
>
> module api {
>      exports api;
>      uses spi;
> }
>
> The default implementation will be non-public classes in the same
> package as the public API classes. The `uses spi` is stand in for
> whatever the service type that some other implementation can provide
> (assume it is indeed pluggable, why else would they be separated in the
> first place?).
>
> If you don't want to combine the API and implementation into the same
> module then you'll have to move the implementation to another package so
> you have something like the following fully encapsulated implementation:
>
> module impl {
>      requires api;
>      provides spi with impl;
> }
>
> Different run-time packages means they can't use package-privates. If
> there is an implementation-specific/extension API then impl will need to
> export that package. There will be presumably be api types in the impl
> specific API so the requires would change to `requires transitive api`.
> OtherImpl will `requires impl`.

I see.

bye Jochen