It seems like it has significant downsides. But us...

# gradle

[snowe]

It seems like it has significant downsides. But using delegated properties isn't really clean either.

[Czar]

I'm using it in my larger projects. What downsides have you noticed and compared to what? 👀

[snowe]

one downside I can see is that if you have a plugin that automatically removes -SNAPSHOT then you've got to rewrite it to somehow rewrite kotlin code.

another downside is that the version is now abstracted 2 clicks away. Whereas before you could keep it in gradle.properties now you either have to cmd/ctrl click to the dependencies and then to the versions from there, or you have to navigate the buildSrc directory.

[snowe]

another downside is that you depend on kotlin completion in gradle files which so far for me is extremely slow.

[Czar]

Ah, ok, those are probably project specific. I was curious if I'm missing something.
Projects I'm using this approach for are large multi-module setups. Kotlin completion is a saviour - it isn't slow for me, well, delay is there, but it is less than a second usually, so I don't mind too much.
Keeping deps in gradle.properties forces you to go to that file each time you need to use a dependency. with buildSrc you only need to go there to change something.
Rewriting SNAPSHOTS - I don't have such use-case.

So for me this method is much better than anything else I've tried. But yeah, probably not for everyone 🙂

[snowe]

Keeping deps in gradle.properties forces you to go to that file each time you need to use a dependency. with buildSrc you only need to go there to change something.

I don't understand what you mean here. I only store versions in gradle.properties and then I can set them up as extra properties in the root build.gradle.kts and then reference them in every module with interpolation.

[Czar]

Ah and another bonus for me is the ability to put docs on dependencies - e.g. short explainers, why one option was use over another, or sometimes a warning not to do something with a dep.

[snowe]

hmm. that's pretty neat...

[Czar]

I don't understand what you mean here.

I see, I missed the ext part 🙂 I remember having a setup like that, completion wasn't always working unfortunately + I had to edit two different files for each dep, which was a bother.

[snowe]

if there was a way to update the versions to remove -SNAPSHOT I'd definitely do it the buildSrc way. It sounds like it has better advantages...

[Czar]

How does that work? I mean what is the exact use case, why are you removing -SNAPSHOT at build time?

[snowe]

Not at build time. it's for releasing. So if I am going to release library1 to nexus staging repo, it can't have -SNAPSHOT on the end. We also don't want to be depending on any -SNAPSHOT versions. So we can automatically remove that.

[snowe]

I know we could use composite builds to solve that, but I still haven't converted everything from maven to gradle, so we can't. also not sure how people will like that. and not sure if that will be allowed anyway, because we have a bunch of regulations in this industry. It might be partially a security mechanism to require snapshot versions in repos lower than staging.

[Czar]

Let me get this straight.
You have somthing like MainProject-1.0-SNAPSHOT depending on some libs Lib1-1.0-SNAPSHOT..LibN-1.0-SNAPSHOT and when you're releasing you rewrite versions in a properties file to remove SNAPSHOT?

[snowe]

yeah.

[Czar]

wow 🙂

[snowe]

haha

[Czar]

Hm... Something can certainly be done about that... What plugin are you using for that? Is that public or a homebrew one?

[snowe]

I wrote a small plugin. very simple

[snowe]

tasks {
            register("snapshotIncrementer") {
                inputs.file("gradle.properties")
                outputs.file("gradle.properties")
                doFirst {
                    val file = File("$projectDir/gradle.properties")
                    val newLines = file.readLines().map { it.replace("-SNAPSHOT", "") }
                    file.writeText(newLines.joinToString(separator = "\n"))

                    exec {
                        isIgnoreExitValue = true
                        commandLine("git", "commit", "-m", "Removing SNAPSHOT versions", "--", "gradle.properties")
                    }
                }
            }
        }

[Czar]

Ok, so you're basically editing a text file, what's keeping you from doing the same in buildSrc?

[Czar]

Just keep dependencies in Deps object, but instead of Versions object, get the versions from properties

[Czar]

You'd still have that pesky auto-completion performance problem though. I don't know what's that about 😐

[snowe]

yeah. and then it would still be 2 separate files as well.

[gildor]

We also use it and it works perfectly. Agree, autocomplete a bit slow, but still useful, bigger advantage is compile.time validation instead of runtime

[gildor]

Also we use it to reference submodules using enum

[snowe]

Ok. I'll have to figure out how to rewrite the versions. My other issue with this strategy is that it seems less than ideal for non-multimodule projects, and so we would be mixing different types of versioning...