How do you like this approach to organizing dependencies? <https://github.com/Darkos-den/BuildScript...

# gradle

[Loboda Deni]

How do you like this approach to organizing dependencies?
https://github.com/Darkos-den/BuildScriptSample

[Loboda Deni]

I describe from the list and apply using the extension function

[Loboda Deni]

Thus, you can immediately apply a set of dependencies to avoid copy-paste

[louiscad]

Can you give a more precise link? This project has no README, and it's unclear what you're talking about exactly.

[Loboda Deni]

I meant extracting dependencies into enum classes and applying them using the extension function

[louiscad]

Oh I see. I don't like it for several reasons:
1. ALL_CAPS
2. There's no real benefit to use enums there, no use case to have a when expression on them there
3. The version is still hardcoded into the Versions.kt file, which means all build cache invalidation on any upgrade because of buildSrc changes impact in Gradle.

[Loboda Deni]

1. as far as I know enum and should be denoted like that
2. in my opinion it's better than storing dependencies in strings, do you know the better option?
3. I agree

[louiscad]

1. You can use PascalCase too, but I don't like that you end up with all caps, regardless of the why, it's noisy in this case and doesn't help reading/inspecting your build files (as a human).
2. Just using constants is better and simpler IMO

[louiscad]

BTW, I'm working on a better solution: #gradle-refresh-versions
You replace the hardcoded version with a placeholder, and the Gradle plugin will put the version you defined in a separate versions.properties file. And it bundles the constants for many popular dependencies.

It's still WIP (up to date doc is on the develop branch only for now)

[Loboda Deni]

for constants you will have to duplicate version numbers

[louiscad]

You can use string templates in constants so long as it includes only constants.

[louiscad]

otherwise, you can use plain val (optionally with @JvmField)