are zou using implementation, api or compile depen...
# gradle
n
are zou using implementation, api or compile dependency ?
j
oh, is that what that implementation is for, i guess that should be `compile then
n
api
j
what is api for ?
n
it exposes the module to consumers of the library
other alternative is to add
jvaas-provider
as a implementation dependency to all modules
but that kind of clutters the dependency graph
j
is the stuff inside
settings.gradle.kts
necessary ?
n
include ? yes
otherwise gradle will not be able to find the subprojects..
j
ok should that be
include("../jvaas-provider")
or
include("jvaas-provider")
all the modules are on the same level in the root directory
n
but zou have a root project right ?
j
well, these are just loose modules, there's not really a root project
for the prototype i added a settings.gradle.kts with this in it
Copy code
rootProject.name = "jvaas-platform
not sure if it does anything
n
well in which level lies your gradlew binary ?
j
each of these modules have their own
n
i doubt that will work
j
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
n
you can compile submodule on their own via eg.
gradlew :submodule:build
and it will just recompile the other submodules it depends on
j
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
e
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).
j
composite builds looks promosing, let me try that and see if it works
Yay, that works, just had to change my
settings.gradle.kts
Copy code
includeBuild("../jvaas-provider")
Thanks Paul and Nikky for the help!
🎉 1