But you can have two version catalogs with different names

Otherwise, as I said, just declare a second version catalog with a different name

Actually what you had in your original post did that, but that is just a typo 😄

you might also try a symlink? so both project just point to the same file

It is unlikely that this will work, if it were the same content, he wouldn't need to have both, but only one would be fine

Also, symlinks are bad if there is any remote chance a Windows-user needs to work with the build 🙂

You don't need to rename any files

The conventional defaults are, that you have a

libs

catalog that is feed from a

libs.versions.toml

file. But that both are called

libs

is no rule, that's just convention and consistency.

You can also name the version catalog

foo

and feed it from a file called

bar.toml

(the missing

versions.

is not a typo)

Just like a build script does not need to be called

build.gradle.kts

, but could also be called

foo.gradle.kts

for a project called

bar

if you configure it like that

It is not a good idea, but you can do it.

sorry if im just not understanding it. im trying a few renames on my end and it still won't compile. looks like if i rename my submodules toml, then i would need to update all references of libs.* in my submodule

looks like if i rename my submodules toml, then i would need to update all references of libs.* in my submodule

I think we are at a point where you need to shown an MCVE. You probably omit the small little detail that makes me not giving the answer you need.

Currently I have

gradle/
  libs.versions.toml
submodules/
  mylibrary1/
    gradle/
    libs.versions.toml

In my root project settings.gradle.kts I have

versionCatalogs {
    create("libs") { from(files("submodules/mylibrary1/gradle/libs.versions.toml")) }
}

When I try to sync, I get a "You can only call the 'from' method a single time" If I update my root project settings.gradle.kts to

versionCatalogs {
    create("submoduleLibs") { from(files("submodules/mylibrary1/gradle/libs.versions.toml")) }
}

then I get build errors in

submodules/mylibrary1/mysdk/build.gradle.kts

of "Unresolved reference to version catalog" when it tries to compile

alias(libs.plugins.android.library)

. If I change it to

alias(submoduleLibs.plugins.android.library)

then it works. But I'd prefer to not have to change all of the

libs

references in mylibrary1 to

submoduleLibs

so that's where it's currently not clicking for me of "NO, you can name the file anything you like, including the current name" because it seems like I still have to go and update all of my usages of

libs.*

in mylibrary1.

... as you just have seen

Change the

include(":mysdk")

to

includeBuild("submodules/mylibrary1")

and your

implementation(project("mysdk"))

to

implementation("group-of-sdk:mysdk")

and you should be fine and also no problems with version catalog, as

mysdk´

uses the version catalog of its own build which is totally independent from your root build, and just happens to be built before as far as necessary to satisfy the dependency.

and then everything stays isolated (exactly what i was looking for)!

Change the

include(":mysdk")

to

includeBuild("submodules/mylibrary1")

Done

implementation(project("mysdk"))

to

implementation("group-of-sdk:mysdk")

Wont build "String module notation 'com.mygroupname.sdk:mysdk' is invalid" FWIW, I'm using the com.mygroupname.sdk from the sdks modules publishing block (maven) where we declared a groupId of "com.mygroupname.sdk", but I'm guessing maybe I shouldn't be using the maven publishing blocks group id?

If you change group or name in the publishing block, for example a simple

includeBuild

will not work as you changed the identity and so you need to add manual substitution rules

But much cleaner would be if you not manipulate the publication

Regarding

Wont build "String module notation 'com.mygroupname.sdk:mysdk' is invalid"

can you show a build scan, or maybe the full error? Did you copy it or type it. If you typed it you might fixed the error on the fly. Because the notation should be fine.

I will remove the group and name in the publishing block and see if that'll work.

It will probably not solve an invalid string notation

But once you fixed the invalid notation, it might fix the error you get then, that it is not found as you changed the coordinates in the publishing block 😄

I want to say if you are still going to publish things out for consumption outside of the composite build you do need it so your pom/module files have the correct info in them?

That might be correct indeed, yes.

Or maybe not, one needs to try.

If it is, then that would be bad actually

And then the pom for external consumers would say you work with version 1 while you actually might need version 5

If that is really the case, I would recommend using a binary dependency from published component and just use composite build locally during developing the library further. That is how I usually do it.

One other important note is, that you have to keep the Gradle versions in sync. Regarding the Gradle version the isolation stops. The Gradle version of the including build is used for both builds, so the included build has to be compatible with that, so best is if both builds are written for the same Gradle version and stay in sync.

Got it working! Woot woot! thank you @Vampire and @TrevJonez before

./gradlew projects

------------------------------------------------------------
Root project 'MyApp'
------------------------------------------------------------

Root project 'MyApp'
+--- Project ':app'
\--- Project ':mylibrary'

after

------------------------------------------------------------
Root project 'MyApp'
------------------------------------------------------------

Root project 'MyApp'
\--- Project ':app'

Included builds:

\--- Included build ':mylibrary1'

The line I needed was (which of course seems so obvious now)

implementation("mylibrary1:mylibrary")

Point of clarification "A given project should always only belong to exactly one build." What does it mean for a project to "belong to a build"? does that mean it should only be in a single "include()" statement? or is there some other thing that makes a project belong to a build?