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" <blackd...@gmx.org> > À: "jigsaw-dev" <jigsaw-dev@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
