This message was deleted.

That page you mentioned - i.e. version catalogs - is exactly the way to go. All those plugins that exist - the are multiple - were just created because version catalogs did not exist. And especially in the TOML variant they are excellent, because unlike having some buildsrc constants or Gradle properties or similar, it will not invalidate anything if you change a version, only the tasks that really use that specific version.

It's objectively inferior by the criteria I established at the top. 1. minimal changes to your

build.gradle(.kts)

files • With version catalogs + TOML files, you basically have to rewrite each

dependencies

block. • With

gradle-consistent-versions

, you only need to remove the versions. 3. easy to setup and use • You don't have to learn any new concepts for `gradle-consistent-versions`; the

versions.props

file is about as easy and intuitive as it gets. ◦ To understand how this plugin works, you just need to read the short "Here's how the

gradle-consistent-versions

plugin rates on those criteria: 1. [...] 2. [...] 3. [...]" blurb from my original post. • For the "recommended" solution, you have to learn two new concepts: version catalogs and the Gradle TOML file format. ◦ While neither concept is super-hard to learn, it's unnecessary complexity compared to simplicity of

versions.props

. ◦ There's also a LOT of reading you have to do on that documentation page before you finally learn enough to use the "recommended" solution.

versions.lock

is a nice bonus, too: it provides a compact, easy-to-understand representation of your prod classpath.

gradle-consistent-versions

is actively developed as well; the authors clearly don't view it as something that was made obsolete by version catalogs and TOML files. • The latest release, 2.16.0, was released this October. • Version 2.0.0 was released in July 2021; Gradle 7 existed back then.

Use whatever makes you happy. I just told you what my recommendation is, which also happens to be the official standard and recommended solution, with advantages that plugin does not have, including things like support by

refreshVersions

plugin that can add all newer versions of the libraries as comments for you to pick from, other tools being able to simply parse it, not invalidating builds unnecessarily, and so on. If you don't want all the advantages and only rate for your listed criteria, use whatever makes you most happy. 🙂

Philosophically, I prefer things that are simple and easy-to-use for the average developer, vs. unnecessarily complex build logic that primarily appeals to build engineers--but does have some advanced bells and whistles that most people won't use. (That's not a foreign philosophy, either; it does overlap quite a bit with the philosophy of Declarative Gradle.) You're also not getting your facts straight here, either. E.g., on invalidating builds unnecessarily, I upgraded one version in

versions.props

, and after I ran

./gradlew --write-locks

,

./gradlew build

, it only rebuilt the one module that used said dependency. Sharing dependency versions is a core problem for essentially every Gradle multi-module build. Only a small subset of those multi-module builds use the

refreshVersions

plugin. I would prefer something which makes the core user experience better for everyone, vs. something that has an extra bell that only a small subset of that group uses.

I don't agree that it "has an additional bell". Using that plugin is an additional bell, as the average non-build-engineer does not know that plugin and how it works, but the chances that she knows the standard feature that imho every builds should use are not that low. It is also much more convenient to use with having IDE completion of the version catalog entries and so on. But as I said, use whatever works best for you. You asked for opinions, I gave you mine. If you don't want to adopt it, that's perfectly fine.

Missing the forest for the trees. The forest: "I have a multi-module Gradle build. I just want to share dependency versions between modules." Option 1 Palantir: Easy. 1) Remove the version from your dependencies. 2) Add this simple snippet to the root build file. 3) Add a super-simple

versions.props

file to the root dir. (You'll occasionally need to run

./gradlew --write-locks

.) User: Oh yeah, that's super-easy. Option 2 Gradle: Well first, let me explain how version catalogs work. User: Uh...OK.... Gradle: Now let me explain the format of our TOML file. User: Seems like overkill, maybe I'll just use Palantir's solution. Gradle: It's super-easy! If you have any questions, you can read 2000+ words of documentation which explains how all this works. (Note: I counted.) User: Yeah, definitely going with Palantir's solution. Gradle: But you can get IDE auto-completion with version catalogs! User: [already finished implementing Palantir's solution] Nah, I'm good. Option 2 almost reminds me of a mini-. (My thanks to whoever leaked that internal Google video; it's a classic.) "I just want to serve 5 terabytes of data..."

Well, we are in different forests apparently. My users' reaction was "wow, that's much nicer, undertandable, and usable than this pesky properties file we had before". Also you - and especially the average user - does not need to read the 2000+ words, that explain the feature in detail and all the possibilities it has. She just has to see the simple and intuitive toml file and use the type-safe completion aware accessors. Also, please don't call me Gradle, I'm not affiliated with Gradle in any way, I'm just a user like you. And again, you asked for opinion / advice. I provided mine from experience. If you don't like it, just ignore it and use whatever works out best for you.

Fine,

s/Gradle:/???:/g

, it's the same lesson regardless of who

???

is. (Missing the forest for the trees again.)

My users' reaction was "wow, that's much nicer, undertandable, and usable than this pesky properties file we had before".

Clearly a build engineer trying to masquerade as a user. The typical user actually likes

versions.props

because it's a dead-easy, intuitive format for specifying dependency versions. Only build engineers seem to have this strange vendetta against properties files. (Under the hood,

gradle-consisent-versions

is way more sophisticated and well-engineered than the past properties-based solutions you have in mind, but that detail is more relevant to build engineers.)

She just has to see the simple and intuitive toml file and use the type-safe completion aware accessors.

Did you not see the skit? You've already lost the user at this point. The user did not ask for "type-safe completion aware accessors." They just want to share version dependencies between modules. It's really that simple. Feel free to admire the "beauty" of version catalogs and a custom TOML format; I'll take the dead-easy simplicity of that "pesky properties file."

> Clearly a build engineer trying to masquerade as a user. Do you intentionally try to upset me for good? Or why are you blaming me for greenwashing? Those users that said this are definitely no build engineers, not the faintest least. I'll just stop now reading and responding here, as you seem to just intend to bully around and that's not worth my time and energy. 👋 If you don't want to hear opinions differing from yours, you should probably not ask for them.

Go read the original post. I asked for "the best simple option for sharing dependency versions in a multi-module build." I then laid out a reasonable set of criteria by which we can evaluate the simplicity of any option. You completely ignored that criteria, and tried to explain that I should really care about this other set of criteria instead--criteria that has little to do with the simplicity of the solution. Unsurprisingly, it didn't go well for you. (And if you ever exhibited the same behavior with customers in the real world, it wouldn't go much better, to put it lightly.) I didn't ask for the best option according to your subjective criteria; I asked for "the best simple option." Me pointing that out is not bullying.