excluding transitive module

[Alex Buckley]

On 4/14/2020 3:12 AM, Jochen Theodorou wrote:
> 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.

>> How does SharedApi locate the implementation?
> 
> It does not, there is no SPI. It just implements the interfaces

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

All the talk of "implements the same packages" and "an implementation of 
the API" and "just implements the interfaces" is besides the point. 
There are no services here. All the module system has to work with are 
the packages exported by SharedApi and SharedApiImpl. It's fine for 
Library1 to require SharedApi, and for Library2 to require 
SharedApiImpl, but if the exported packages overlap, then it's not fine 
for Project to require, indirectly, both SharedApi (via Library1) and 
SharedApiImpl (via Library2). That is, SharedApi and SharedApiImpl are 
not composable. If you had put them both on the classpath in JDK 8, then 
you would have had a broken system. If you want to compose an 
application that includes both, then one of them has to change.

There is no need to speak of "transitive" modules because `requires 
transitive` has not entered the picture.

Alex