Hello. I've a question about exposing dependencies...

# gradle

[Roman Konstantynovskyi]

Hello.
I've a question about exposing dependencies in libs builded with gradle.
In my spring boot application (A) I'm using my own starter (S1), which use another starter(S2), which use a library (L).
A -> S1 -> S2 -> L
In my starter (S1) I can use all classes from the library (L). But if I add my starter (S1) as a dependency to my application (A) then I can't use classes from the library and from the second starter (S2), because they aren't in compileClasspath.
In my starter (S1) I'm adding second starter as implementation. And also I use this configuration for adding my starter to application.
I've read that to expose dependency I should use ``java-library`` plugin for gradle and use api configuration in my starter (S1), but this didn't help me 😞
And if I add S2 to my S1 using deprecated compile configuration all works well. 🤔

build.gradle.kts (starter S1)

plugins {
	// other plugins
	`java-library`
}

dependencies {
    // other dependencies
	api("some:starter:1.0.0") // starter S2
}

build.gradle.kts (application A)

dependencies {
    // other dependencies
	implementation("own:starter:1.0.0") // starter S1
}

[spand]

api is present in the standard kotlin plugin

[spand]

No need for java-library

[Roman Konstantynovskyi]

Without java-library this also not working as I expect

[Vampire]

If L is in the API of S1, it should be api otherwise it should be implementation.
"in the API" means super-classes, type parameters, parameter types and return types of the public api of S1.
If L is in S1 only used for implementing logic or in private or package-private stuff, it should be implementation.
If it is in api, it will also be in the compile classpath of downstream project, in your case A.
If it is in implementation, it will not be in the compile classpath of A just by depending on S1.
If you use L directly in A yourself, you should add an explicit dependency on L instead of depending on the transitive dependency of S1.