Meaningless variable names

[ivoberger]

Great plugin, I got some quite useless variable names though:

const val core_ktx: String = "androidx.core:core-ktx:" + Versions.core_ktx
const val core_kt: String = "ru.ztrap.iconics:core-kt:" + Versions.core_kt

They are both kotlin extensions but for very different libraries yet cant be distinguished by the variable name. As kt and ktx endings are quite common for such libraries maybe check for combinations of that and the meaningless words you already check against would be a good idea. Basically add a list of suffixes.

On the other hand some of the constants get very long:

const val jmfayard_github_io_gradle_kotlin_dsl_libs_gradle_plugin: String =
            "jmfayard.github.io.gradle-kotlin-dsl-libs:jmfayard.github.io.gradle-kotlin-dsl-libs.gradle.plugin:" + Versions.jmfayard_github_io_gradle_kotlin_dsl_libs_gradle_plugin

That's the most extreme example I had in my projects. I'd suggest cutting common segments like github and TLDs from the name to get something like the following:

const val jmfayard_kotlin_dsl_libs_gradle_plugin: String =
            "jmfayard.github.io.gradle-kotlin-dsl-libs:jmfayard.github.io.gradle-kotlin-dsl-libs.gradle.plugin:" + Versions.jmfayard_gradle_kotlin_dsl_libs_gradle_plugin

Still long but better.

I can take a see if I can make a pull request with those changes in the next days. I'm of course open for better solutions, these are just my initial thoughts.

[jmfayard]

Hello @IIIuminator

Adding a list of suffixes sounds like a great idea! I would be happy to have a pull request on that.

The part about making FDQN names shorter seems more difficult to get right in all cases, I would prefer postpone it until we have a better understanding of it.

Update: We have to think about what happens when someone updates the plugin to a newer version and runs it again. Libs.core_ktx would not exist anymore so that's a breaking change. I am still for it because it's a reasonable breaking change, it should just be documented in the CHANGELOG.

On the other hand, if we change the FDQN to something nicer, it breaks a lot of existing builds, so it's not worth it. Better be conservative.

[ivoberger]

Alright. I'll take a look tomorrow. Will take a little time though, have never done any work on a gradle plugin.

[jmfayard]

Alright. I'll take a look tomorrow. Will take a little time though, have never done any work on a gradle plugin.

Hold on a bit @IIIuminator
I've decided I don't want to be stuck forever with a bad naming so I want to complete first the renaming of the project to gradle buildSrcVersions #26

Also there is a cool new feature in Gradle 5.1 that will make it easier for you to work on a Gradle plugin without having to publish the plugin locally.

I will take care of that and inform you when I am done.

[ivoberger]

Yeah sure. I'll wait until it's done.

[ivoberger]

on a different project it got the same libraries right.. there's a lot of other stuff as well but nothing with core.
Got

/**
 * [core-ktx website](https://developer.android.com/tools/extras/support-library.html) */
const val androidx_core_core_ktx: String =
            "androidx.core:core-ktx:" + Versions.androidx_core_core_ktx

and

/**
* [core-ktx website](https://github.com/zTrap/Android-Iconics-Kt) */
const val ru_ztrap_iconics_core_ktx: String =
            "ru.ztrap.iconics:core-ktx:" + Versions.ru_ztrap_iconics_core_ktx

[jmfayard]

@IIIuminator it's because if two libraries have the same name (here core-ktx), the plugin detects it and uses the FDQN for both.
The "meaningless names" feature is that we don't wait for the conflict to happen and always use the FDQN

[jmfayard]

Two things: @IIIuminator

1. Before Gradle 5.1 is released, hacking on the plugin is not easy so I think I will handle the issue myself.

2. A more general solution that doesn't break builds with an older version of the plugin is that you declare explicitely for which additional libs the FDQN should be used by default. In your case that would be:

// build.gradle(.kts)
buildSrcVersions {
  useFdqnFor("core-kt", "core-ktx")
}

What do you think?

[ivoberger]

@IIIuminator it's because if two libraries have the same name (here core-ktx), the plugin detects it and uses the FDQN for both.
The "meaningless names" feature is that we don't wait for the conflict to happen and always use the FDQN

yes of course. That helped me notice that I used the wrong version of the same library in one of the apps. Was already thinking something's fishy 😄

What do you think?

sounds good to me. was thinking myself that being able to configure it might be the best solution. Using a config option it should be possible to remedy these really long names too. have a useFdqnFor and a removeFdqnFor option together with FdqnElements so its possible to configure whats removed.

[jmfayard]

@IIIuminator It should be possible in buildSrcVersions 0.3.1

Configuration:

plugins {
  id("de.fayard.buildSrcVersions") version "0.3.1"
   // remove plugin gradle-kotlin-dsl-libs
}

buildSrcVersions {
   useFdqnFor = ['core-ktx', 'core-kt'] // Groovy
   useFdqnFor.set(listOf("core-ktx", "core-kt") // Kotlin
}

I rewrote the README, have a look
https://github.com/jmfayard/buildSrcVersions

[ivoberger]

Looks good. One suggestions: use a vararg parameter instead of a list so its possible to write it like so:
useFdqnFor.set("core-ktx", "core-kt") // Kotlin

[jmfayard]

That would be better but it needs to be interoperable with Groovy and so an Iterable was the simplest way to do that.