are zou using implementation, api or compile dependency ?

oh, is that what that implementation is for, i guess that should be `compile then

api

what is api for ?

it exposes the module to consumers of the library

is the stuff inside

settings.gradle.kts

necessary ?

include ? yes

ok should that be

include("../jvaas-provider")

or

include("jvaas-provider")

but zou have a root project right ?

well, these are just loose modules, there's not really a root project

well in which level lies your gradlew binary ?

each of these modules have their own

i doubt that will work

each of them needs to be compilable on their own, there might be 200 of them soon. In maven it meant having to compile each individual one every time you do a clean checkout

you can compile submodule on their own via eg.

gradlew :submodule:build

ok, so should i create a build.gradle.kts in the root then? these modules should also be accessible to outside projects without bringing in all 200 of them

If what you’re looking for is replacing the need for maven snapshots in the maven local repository maybe Gradle’s composite builds will help. It allows you to connect otherwise independent gradle builds (may they be single or multi-project).

composite builds looks promosing, let me try that and see if it works