I’m facing a problem in a two layers dependency configuration. I have a library A that can use a B dependency, so it is configured with scope implementation. The dependency A is used in an app, with the implementation scope and doesn’t need the B dependency.
What I am attempting to have is an app with the A dependency but not with the B one. Unfortunately, the B one is also loaded.
Normally using the implementation scope in the app and the A library would not load the B dependency, is it?
Please advise
EDIT :
I also have an error while building the project. I don’t know if it can have something to do with my current problem
Errors occurred while build effective model from /home/pilak/.gradle/caches/modules-2/files-2.1/com.sun.xml.bind/jaxb-osgi/2.2.10/c926a537af564ec047ec6308df1d0d2a03364a86/jaxb-osgi-2.2.10.pom:
'dependencyManagement.dependencies.dependency.systemPath' for com.sun:tools:jar must specify an absolute path but is ${tools.jar} in com.sun.xml.bind:jaxb-osgi:2.2.10
No, that is incorrect. The usage of implementation vs. api is related to the classes that are visible on the compile classpath vs. the runtime classpath. If the A library has an implementation dependency on B, this just means that the app can’t compile against classes in B directly, but B still must be loaded in order to not have a ClassNotFoundException when using the parts of A that use B with typical usage.
However, if you have a case where you know that the app will never need to use the specific features in A that have the dependency on B, you can exclude B. This is an independent decision though. It doesn’t have anything to do with using implementation.
I understand now better what happens.
In my case, I only have to put dependency B in compileOnly into A, and use testImplementation to be able to build project in build.gradle
Then in the app, I can add A library dependency in implementation.
That is useful in my Spring Boot project where I have a custom actuator library (library A), that doesn’t necessary need spring-data dependency (library B), but can compile with it and load beans attached to it if the library B is in classpath.