I'm curious why was invented such naming system inside of the version catalog (TOML) where dependencies using "-" like

androidx-compose-bom

and inside of Gradle scripts "-" are replaced by "." this is so awful solution and it is used everywhere 😭 It completely prevent to use code suggestion / auto completion inside of IDE. When you have something like

androidx-compose-material3-adaptive-navigation

and you don't remember the whole name, just know that it is navigation, you are lost. With

androidxComposeMaterial3AdaptiveNavigation

, you can write just

nav

and you are done. Or if you want to add some dependency even before project is properly synced, with camel case you can just copy&paste it, with current format is a huge pain. The same if you are using currently popular

build-logic

in project plugins to simplify multi-module setup. Then you need to use

add("implementation", libs.findLibrary("androidx.compose.material3.adaptive.navigation").get())

And you need to manually handle replacing

-

by

.

. Or when you want to found where it is used, you cannot just select text and search. Is there any petition for stop using

a-b-c

syntax. I would sign in immediately 😉.

If you have defined in your version catalog:

[libraries]
androidx-compose-material3-adaptive-navigation = { ... }

Then using the type unsafe API you will use

androidx-compose-material3-adaptive-navigation

, not `androidx.compose.material3.adaptive.navigation`:

versionCatalog.findLibrary("androidx-compose-material3-adaptive-navigation").ifPresent { implementation(it) }

See here: https://docs.gradle.org/current/userguide/platforms.html#sub:type-unsafe-access-to-catalog But, in any case, if you want camel case version catalog names, then you can use camel case:

[libraries]
androidxComposeMaterial3AdaptiveNavigation = { ... }

Using the type safe API you will reference it using:

implementation(libs.androidxComposeMaterial3AdaptiveNavigation)

In my opinion, I would't have a name like

androidx-compose-material3-adaptive-navigation

in my version catalog because it's way too lengthy. I try to keep my version catalog IDs only 2 layers deep. I would probably do something like this:

[libraries]
androidx-adaptiveNavigation = { ... }

All

androidx

dependencies would be grouped that way. Then you would reference it like:

implementation(libs.androidx.adaptiveNavigation)

But, the naming is all personal preference. You can name entries however you like. Here is a blog post that talks about best practices for naming version catalog entries: https://blog.gradle.org/best-practices-naming-version-catalog-entries Personally, I think translating

-

into

.

makes sense. What else would you use? If it kept the

-

, then everything needs to be surrounded by backticks

and you would have no way to group common dependencies. So you have:

```implementation(libs.`androidx-compose-material3-adaptive-navigation`)

Yes. I think that problem is already in Gradle official suggestion, it telling using "-" For example this • GA:

com.bmuschko:gradle-docker-plugin

• Wrong:

bmuschko-gradleDockerPlugin

,

plugin-bmuschko-docker

• Right:

bmuschko-docker-plugin

Why I must remember something so complicated like

bmuschko

to be able to add docker to dependencies? Why? If name would be

bmuschkoGradleDockerPlugin

, would write just

docker

and IDE will provider my suggestion with whole name, because IDE allows to use any part of the name. The same with

androidx-adaptiveNavigation

You need to remember that it is part of androix, if it would be

androidxAdaptiveNavigation

you still can write

androidx

and IDE will display list of all androidx dependencies, but you can also directly write just

nav

At the end in reality in all Android example projects it looks like this 😞 https://github.com/android/compose-samples/blob/main/Jetcaster/gradle/libs.versions.toml#L83 It is impossible to find something other way than open toml file directly and search there.

TBH sometimes, I just wish Gradle had gone with the lenghty/opinionated version:

com.bmuschko:gradle-docker-plugin

=>

comBmuschkoGradleDockerPlugin

Sure it's verbose as hell but maven coordinates are already verbose as hell and no one complains

To me, part of the appeal of version catalogs is that they allow my provide succinct aliases for dependencies.

Fair enough I guess

Naming is hard. 😆 Everyone will have a different opinion about it.

It's not only hard, it is one of the hardest things in software development overall 😄

image.png

Also know the heaviest things in the world?

🤔

The heaviest thing in the world is my

~/.gradle

😂 (for very good reasons)

One second, Teams is hanging

Yes. One level is good/bad naming, but naming that don't allows you to use IDE auto completion is another (worse) level for me. 😞

Well, that's always a matter of taste and which holy war you wanna fight. Believe it or not, there are people putting opening curly brace on a new line and even think that is a good thing to do. 😲 Poor lost souls.

Why not using the artifact name directly 🤷‍♂️, what is wrong with dashes? This is an example of Gradle unnecessary complexity added

It''s neither unnecessary and I don't find it complex. And the problem with dashes was outlined above already

Oh I see, sorry it was a long post and I skipped that part. 👍

I have strong opinions about this and disagree to some extent with the "official" recommendations (note: as the initial designer of this feature, I think I have right to complain ;)). The point about having

-

translated into

.

is kind of obvious: a minus is an operator in scripts. Then comes the point about using

androidxAdaptiveNavigation

vs

androidx.adaptative.navigation

. The key to me is hierarchy. You should split the name whenever a dependency can be seen as as subcategory. eg,

androidx.adaptativeNavigation

would make better sense to me than

androidxAdaptativeNavigation

because it's an

androidx

category, and

adaptativeNativation

is a single unit. We can argue about using

androidx.adaptative.navigation

too. In theory, I would tend to think that it shouldn't be used, however, because of the cognitive overhead of figuring out if you should capitalize or not, I think it's ok. It's actually a convention we have eventually adopted in Micronaut, it makes things easier for users. Long story short, I'm far from fond of

capitalizedLibraryNames

, because it's putting all libraries in a single bucket, and completely hides one of the best features of catalogs which is categorizing them.

To me the categorization is arbitrary. There is a notion of maven group id, there is a notion of bundle. Adding yet another concept is more cognitive load for (IMO) little value.

It is like with most holy wars. Some like it the one way, some like it the other way. And neither will convince the others.

Only the Gradle empire can settle the war 😄

yup. all I'm saying is that having half a million suggestions when I hit ctrl+space is not great, and that having to think whether I should use a capital letter or not either. At the same time IntelliJ could improve completion specifically on nested aliases too.

@melix I fully agree that it is good to have hierarchy, but in the reality it simply doesn't work 😞 You need to remember in which group dependency is. androidx is quite special bigger group. But there is not so much big groups. And sometimes you even need dependencies from multiple groups. For example

androidx.adaptativeNavigation

and

destination.navigation

when I will write

library.nav

I would like to see both navigation in auto complete. From my point of view

androidxAdaptativeNavigation

is still structured, But I was discussing it also with android studio developers and they told that maybe would be possible to enhance autocomplete suggestions to search also in subcategories.

Who prevents you from putting both in the

nav

group? You as the one writing the version catalog control which groups exist and what is in which group.

There's absolutely no difference between strategies here. It's the same whether you use dots or not. And one would argue that if you don't use catalogs, it's even worse because you have no completion at all. And yes, it's up to the IDE authors to improve completion for this particular use case.

Dots simply break autocompletion, this is only what I wanted to say 😉

Complain to the IDE vendor to add a special case for version catalogs, that's what melix said 😄