excluding transitive module

[Remi Forax]

Hi Jochen,
JPMS has no notion of of API and implementation of the same jar. It's a concept of your build tool and not something JPMS knows.

The notion of compilation dependencies and runtime dependencies is not a concept of JPMS but a concept of your build tools.

In term of JPMS, if you want to be able to use a jar at compile time and another one at runtime,
both should have the same module name, in fact they should have exactly the same module descriptor (the same module-info). 

So in term of dependency,
- for,Maven/Gradle, the compile dependency will use SharedAPI and the runtime dependency SharedApiImpl
- for JPMS, both have the same module-info and if you want to depend on that module, just require it.

>From the Maven Central POV, obviously, you have two jars so they can not have the same arfifact ID (coordinate), but they contains the same module-info.class.

regards,
Rémi

----- Mail original -----
> De: "Jochen Theodorou" <blackdrag at gmx.org>
> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mardi 14 Avril 2020 10:24:34
> Objet: excluding transitive module

> 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.
> 
> Scenario 1:
> 
> What would seem to be logic to me is to exclude SharedApi, but does
> SomeLibrary then need its requires to be changed to SharedApiImpl? How
> would I do that if I cannot change SomeLibrary?
> 
> Scenario 2:
> 
> Let us assume I could change the module-info of SomeLibrary. How would I
> express that Shared API is compilation only? Is that what "requires
> SomeLibrary for compilation" would be for?
> 
> bye Jochen