splitties/refreshversions

Life is too short to google for dependencies and versions

refreshversions's Issues

versionsOnlyMode for single-module Gradle projects

Status:
Improved and now part of "gradle :refreshVersions" generates gradle.properties with versions and available updates

---

Status: released in v0.5.0

Context: my Gradle plugin buildSrcVersions extends the gradle-versions-plugin. It scan your Gradle builds to search for available updates to your dependencies and generate code to make it extra-convenient. This new feature is designed for simple (single-module) Gradle projects for which it provides an easy solution to a simple problem.

New feature: versionsOnlyMode

The plugin can now be configured like this

// build.gradle.kts
plugins {
  id("de.fayard.buildSrcVersions").version("0.5.0")
}

buildSrcVersions {
   versionsOnlyMode = VersionsOnlyMode.KOTLIN_VAL
   versionsOnlyFile = "build.gradle.kts"
}

or

// build.gradle
plugins {
  id 'de.fayard.buildSrcVersions ' version '0.5.0'
}
buildSrcVersions {
   versionsOnlyMode = "GROOVY_DEV"
   versionsOnlyFile = "build.gradle"
}

versionsOnlyMode is an enum:

• KOTLIN_VAL will generate val okhttp = "3.2.0"
• KOTLIN_OBJECT will generate the same file as Versions.kt in the default mode
• GROOVY_DEF will generate def okhttp = '3.2.0'
• GROOVY_EXT will generate ext { okhttp = '3.2.0' }
• GRADLE_PROPERTIES will generate okhttp=3.2.0

First run

The first time you run ./gradle buildSrcVersions, it will print something like:

// <buildSrcVersions>
// Generated by ./gradle buildSrcVersions
// See https://github.com/jmfayard/buildSrcVersions/issues/55
val org_jetbrains_kotlin_jvm_gradle_plugin = "1.3.11"  // available: "1.3.50"
val kotlin_stdlib_jdk8 = "1.3.50"
val okhttp = "4.1.0"
val okio = "2.0.0"
// </buildSrcVersions>

Copy/paste this snippet in versionsOnlyFile at whichever place makes sense for your build.

Use those versions like you already do.

dependencies {
    // <buildSrcVersions>
    // Generated by ./gradle buildSrcVersions
    // See https://github.com/jmfayard/buildSrcVersions/issues/55
    val okio = "2.0.0"
    val okhttp = "4.1.0" // available: "4.1.1"
    val org_jetbrains_kotlin = "1.3.50"
    // </buildSrcVersions>

    implementation(kotlin("stdlib-jdk8", org_jetbrains_kotlin))
    implementation("com.squareup.okhttp3:okhttp:$okhttp")
    implementation("com.squareup.okio:okio:$okio")
}

Dependency updates

Next time you want to search for dependencies updates, run again

./gradle buildSrcVersions,

The plugin will regenerate the block <buildSrcVersions>....</buildSrcVersions> inside buildFile

It's the same approach that works well for the default mode of the plugin: a comment inform you about the update. You can update the build:

(Press Delete to update.)

Context and Motivation

Simple things should be easy, complex things should be possible
-- Larry Wall

The basic idea of the Gradle buildSrcVersions plugin has been until now to generate two files, Libs.kt and Versions.kt inside the buildSrc

I'm coming from an android background where the build is by default multi-modules and where the Android Gradle Plugin in particular is very complex. In this context, the buildSrc is an elegant and powerful tool to maintain developer sanity. It solves the complex things should be possible part.

As I have migrated to the backend though, I now have much simpler, single-module Gradle builds. Sure, I can still extract my dependencies to buildSrc, but why, you may ask, is it useful to extract there my dependencies used exactly oncer?

The correct answer: It is useless. I only need the Versions

The versionsOnlyMode is the attempt to get right the part: Simple things should be easy part

How to search for updates in other repositories?

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

Searching for dependenvies updates is done by the Gradle Versions plugin

Check its documentation on how to configure it

https://github.com/ben-manes/gradle-versions-plugin

You may want to look at this discussion.
ben-manes/gradle-versions-plugin#274

Another word of advice (which also applies more to the underlying versions plugin) is that at least with gradle 4.9.x the order of repos is critical. As a concrete example, I have a dependency where jcenter has 2.4 as the latest version and mavencentral has 2.3, and depending on which comes first the plugin (and thus your plugin) will report differnt values for the latest version. For most dependencies that might not matter as long as you have either jcenter or mavencentral as the top repo because the are 99% or so in sync anyway.

Use Libs.xxx in Gradle's resolutionStrategy

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

You can use the information from Libs.kt to simplify your resolutionStragy:

val forceDependencies = listOf(Libs.retrofit, Libs.kotlin_reflect, Libs.kotlin_stdlib_jdk7)      // Kotlin
// def forceDependencies = [Libs.retrofit, Libs.kotlin_reflect, Libs.kotlin_stdlib_jdk7]  // Groovy

allprojects {
    configurations.all {
        resolutionStrategy {
            for (dependencyVersion in forceDependencies) {
                force(dependencyVersion)
            }
        }
    }
}

The same principle can be used for the resolutionStragy of plugins

pluginManagement {
    resolutionStrategy {
        eachPlugin {
            val plugin = requested.id.id
            val module = when {
                plugin.startsWith("com.android") -> Libs.com_android_tools_build_gradle
                plugin.startsWith("kotlin")  -> Libs.kotlin_gradle_plugin
                else -> return@eachPlugin
            }
            println("resolutionStrategy for plugin=$plugin : $module")
            useModule(module)
        }
    }
}

Remove buildSrc settings

Feedback from Paul

There shouldn't be any settings in the buildSrc

settings.gradle.kts files mark the boundaries of a gradle build, that explains the Unresolved reference: Config because Config sits in buildSrc up the directory hierarchy, out of the build boundaries

Typo in buildSrcVersions.useFdqnFor method

I believe the acronym for "fully qualified domain name" is FQDN, but the method in buildSrcVersions swaps the Q and the D, making it FDQN.

Exclude some subproject

My project contains deprecated applications. They use old dependecies. I would like to exclude them from syncLibs.

buildSrcVersions.useKotlinSpecificSyntax

Optional feature:

Given this configuration

buildSrcVersions {
  useKotlinSpecificSyntax = true
}

I expect to see code generated like this:

object Versions {
    const val `org.jetbrains.kotlin` = "1.3.50"
}
object Libs {
	const val `kotlin-stdlib-jdk8`: String = "org.jetbrains.kotlin:kotlin-stdlib-jdk8:" + Versions.`org.jetbrains.kotlin`
}

That would work only in build.gradle.kts (Kotlin DSL) so it should be disabled by default.

Add CI & Github Actions

• Investigate how to add CI (CircleCi? Travis?)
• Have a look at those Github Actions

Links:

• https://docs.travis-ci.com/
• https://circleci.com/docs/2.0/
• https://github.com/features/actions/

Updating buildSrcVersions itself

• Since: 0.4.1
• Only for build.gradle.kts

--

Provided that you have run ./gradle buildSrcVersions once with a version 0.4.1 or better, you can replace the plugin declaration with a typesafe accessor

plugins {
-  id("de.fayard.buildSrcVersions") version "0.4.1"
+ buildSrcVersions
}

Now you can update the plugin itself like any other dependency by updating Versions.de_fayard_buildsrcversions_gradle_plugin

Provide `apply plugin` configuration

Probably not everyone migrated to plugins {} syntax and I expect the old format to stick for a while. Would be nice to have both options documented. It took some googling to discover that the classpath is classpath 'de.fayard.buildSrcVersions:de.fayard.buildSrcVersions.gradle.plugin:0.4.1'

Support for Gradle plugins using "id"

I am using Kotlin as language and adding plugins by calling:

id("de.fayard.buildSrcVersions") version "0.4."

I am able to use the generated version number by calling:

id("de.fayard.buildSrcVersions") version Versions.de_fayard_buildsrcversions_gradle_plugin

Unfortunately the string "de.fayard.buildSrcVersions" is not created in Libs. What about creating a third object named "Plugins"?

Wish:
id(Plugins.buildSrcVersions) version Versions.de_fayard_buildsrcversions_gradle_plugin

PS: Great plugin - I love the idea of autogenerating the files and adding comments for newer versions! That is really great!

Plugins information

Find out wether we can generate code about plugins

Something like this:

object Kotlin {
    const val version = "1.3.0-rc-190"
    cconst val id = "kotlin" // used in apply { plugin() }
    const val stdlib = "something:sometzthing:$version" // used in dependencies
    const val pluginModule = "maven:coordinates" // used in settings.gradle.kts
}

extra space at the end of generated Versions object

.. as one could see here.

Thank you for the coolest gradle plugin I've seen maybe in the entire 2018!

Add plugin configuration options

Hi,

Would it be possible to add more plugin configuration options like:

• Option to configure the name of the generated "Libs" file, i.e. "Library", "Libraries", etc.
• Option to change the casing of the generated names, i.e. cammel case, kebab case ... Libs.springBootDevtools instead of Libs.spring_boot_devtools

Great plugin!

Thanks,
Hristo

How to update Gradle itself?

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

Available since 0.6.0

$ ./gradlew refreshVersions add in gradle.properties:

// gradle.properties
version.gradleLatestVersion=5.6.2

Available since: 0.4.0

The standard way to update gradle is to edit the file: gradle/wrapper/gradle-wrapper.properties

The buildSrcVersions also looks for what is the latest available release for Gradle itself.

object Versions {
   // ...

    const val gradleLatestVersion: String = "5.1.1"
}

You can leverage this information by configuring the wrapper task:

Groovy:

// ./build.gradle
wrapper {
}

Kotlin:

// ./build.gradle.kts
tasks.withType<Wrapper> {
    distributionType = Wrapper.DistributionType.ALL
    // with buildSrcVersions
    gradleVersion = Versions.gradleLatestVersion   
    // with refreshVersions
    gradleVersion = findProperty("gradleLatestVersion") as? String ?: gradle.gradleVersion
}

Then this will automatically update Gradle to the latest available release

$ ./gradlew wrapper

Gradle composite build

• Upgrade to Gradle 5.1
• Use its composite build feature that now works for plugin
• Doc https://docs.gradle.org/5.1/userguide/composite_builds.html
• Samples https://github.com/gradle/gradle/tree/master/subprojects/docs/src/samples/compositeBuilds

Apply plugins from included build using plugins { } block
The plugins { } block in build scripts can now be used to refer to plugins defined in included builds. In previous versions of Gradle, this was possible but required some additional boiler-plate code in the settings file. This boiler-plate is now no longer required.
This change makes it super easy to add a test build for a Gradle plugin and streamlines the process of implementing a Gradle plugin. You can also use this feature to conveniently work on changes to a plugin and builds that use that plugin at the same time, to implement a plugin that is both published and used by projects in the same source repository, or to structure a complex build into a number of plugins.
Using the plugins { } block also makes the Gradle Kotlin DSL much more convenient to use.
You can find out more about composite builds in the user manual.

Non-regression tests

Let's say people have added to their build

dependencies {
   compile(Libs.okio)
   compile(Libs.rxjava)
}

Add tests to check that for the same report.json file, we always produce the same identifiers listOf("okio", "rxjava").

Improve dependency update workflow

First, thanks for this wonderful plugin.

I agree that version updates should be confirmed or rejected by the developer. I was using gradle-libraries-plugin, and since my source is in git I was reviewing every change dependencies.json in my favorite git tool after doing updateLibraries.

The point is that this plugin should offer an option the actually change the versions, since I have to review the changes anyway. Having a “remove comments manually” step adds nothing and makes things more complicated.

Also, for creating a .gitignore file: Not everyone is using git, so this plugin should make no assumptions, and I need to manage my own .gitignore file anyway - this shouldn't be there.

Both are topics with what this plugin should be concerned and what are actually tasks that are necessary, but not the responsibility of this plugin.

Thanks
Oliver

Task with path `':dependencyUpdates'` not found

When trying to run ./gradlew buildSrcVersions I'm getting this error:

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':app:buildSrcVersions'.
> Task with path ':dependencyUpdates' not found in project ':app'.

What is the buildSrc module?

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

The directory buildSrc is treated as an included build. Upon discovery of the directory, Gradle automatically compiles and tests this code and puts it in the classpath of your build script. For multi-project builds there can be only one buildSrc directory, which has to sit in the root project directory. buildSrc should be preferred over script plugins as it is easier to maintain, refactor and test the code.

buildSrc uses the same source code conventions applicable to Java and Groovy projects. It also provides direct access to the Gradle API. Additional dependencies can be declared in a dedicated build.gradle under buildSrc.

See more at https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources

A practical example:

// buildSrc/..../Config.kt
object Config {
    const val applicationId = "de.fayard.something"
    const val compileSdkVersion = 27
    const val targetSdkVersion = 27
    const val versionName = "1.0.0"
    const val versionCode = 1
    const val minSdkVersion = 21

   val runsOnCi : Boolean = System.getenv("MY_ENV_VARIABLE") != null
}

You can now use those constants everywhere in the your Gradle biuld and the IDE is giving you auto-complete, in both build.gradle and build.gradle.kts files

Example

// app/build.gradle
android {
    compileSdkVersion(Config.compileSdkVersion)

    defaultConfig {
        minSdkVersion(Config.minSdkVersion)
        targetSdkVersion(Config.targetSdkVersion)
        versionCode = Config.versionCode
        versionName  = Config.versionName
        applicationId = Config.applicationId
    }


}

Android Studio 3.3 & 3.4: broken IDE integration

Update: problem fixed in Android Studio 3.5

---

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

Android Studio 3.3 broke the IDE integration inside the build.gradle files for the code that is available inside the buildSrc module, which is quite sad 😢 This affects users of this plugin (build.gradle.kts files still work though) but also anyone using the buildSrc module

• https://github.com/jmfayard/bug-androidstudio-buildsrc is a minimal project that demonstrate the problem
• Please star bug # 123032843 IDE integration with the Gradle buildSrc module is broken in Android Studio 3.3

Add integration tests with gradleTestKit()

It would be useful to have integration tests powered by gradleTestKit().

For example that would allow to test the plugin with different versions of Gradle like https://github.com/ben-manes/gradle-versions-plugin/blob/master/src/test/groovy/com/github/benmanes/gradle/versions/DifferentGradleVersionsSpec.groovy

Documentation:

• gradle-site-plugin
• Testing Build Logic with TestKit
• https://github.com/ben-manes/gradle-versions-plugin/tree/master/src/test
• Embedding Gradle using the Tooling API
• GradleConenctor
• Developing Custom Gradle Plugins

SyncLibs generate wrong output file

I added these 2 dependencies to the build.gradle file:

"com.android.tools.build:gradle:3.2.1"
"Io.fabric.tools:gradle:1.26.1"

But the object Libs (for these 2 dependencies) is not generated correctly, because I get a mix of 2.
I get only this:
const val com_android_tools_build_gradle: String ="io.fabric.tools:gradle:" + Versions.com_android_tools_build_gradle

which is the fabric library but with the name of the other, while "com.android.tools.build:gradle" is not present

buildSrcVersions --export

Use case: I would like to be able to copy-paste my dependencies across projects.

Proposed solution:
Add a --export feature that would print dependencies used accross all modules

$ ./gradlew buildSrcVersions --export
dependencies {
    implementation("com.squareup.okio:okio:2.1.0")
    implementation( "com.squareup.moshi:moshi:1.7.0")
   // ...
}

Notes:
https://github.com/ben-manes/gradle-versions-plugin#custom-report-format

Invalid Comment linebreak

When running buildSrcVersions I got this linebreak

const val community_material_typeface: String = "3.1.0-rc02" // exceed the version found:
            2.7.94.1

resulting in invalid code. Tired it multiple times (also with Android Studio closed, in case its some auto-format issue) and it happens every time.

`available` wraps around wrong

When the current version is long, newly available version ends up on the next line sans comment marks.

    const val services_utils: String = "1.0.1270-kubernetes-SNAPSHOT-1547233874" // available:
            "1.0.1270"

Detect indent from EditorConfig file

There is now an option to configure the indent for Libs.kt and Versions.kt

buildSrcVersions {
    indent = "  "
}

Even better would be to auto-detect whether a .editorconfig file is already doing it and do the right thing by default.

https://editorconfig.org/

When opening a file, EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory. A search for .editorconfig files will stop if the root filepath is reached or an EditorConfig file with root=true is found

indent_style: set to tab or space to use hard tabs or soft tabs respectively.

indent_size: a whole number defining the number of columns used for each indentation level and the width of soft tabs (when supported). When set to tab, the value of tab_width (if specified) will be used.

Plugin configuration

• Available since: 0.4.2
• Version documented: 0.7.0

Add the plugin de.fayard.refreshVersions to your project

Edit your root build.gradle(.kts) file

plugins {
  id("de.fayard.refreshVersions") version "$VERSION"
}
// Don't put any code before the buildscript {} and plugins {} block

// See configuration options at https://github.com/jmfayard/buildSrcVersions/issues/53
buildSrcVersions {
    
}

Used de.fayard.buildSrcVersions before? See Long term plan: focus on refreshVersions

The configuration options are described in #53 Plugin Configuration

You can find the latest $VERSION at https://plugins.gradle.org/plugin/de.fayard.refreshVersions

Default configuration

/**
 * Use ./gradlew refreshVersions to find available updates
 * See https://github.com/jmfayard/buildSrcVersions/issues/77
 *
 * Use ./gradlew buildSrcVersions to generate buildSrc/src/main/Libs.kt
 * See https://github.com/jmfayard/buildSrcVersions/issues/88
 */
buildSrcVersions {
    // See configuration options at https://github.com/jmfayard/buildSrcVersions/issues/53    

    rejectVersionIf {
      isNonStable(candidate.version)
    }
    //alwaysUpdateVersions()
    orderBy = OrderBy.GROUP_AND_LENGTH
    versionsOnlyMode = null
    versionsOnlyFile = null
    indent = null
    renameLibs = "Libs"
    renameVersions = "Versions"
    useFqdnFor() // nothing

}

Things you can configure

• orderBy = OrderBy.GROUP_AND_ALPHABETICAL to sort gradle.properties in alphabetical order.
• indent = "\t" to use tabs instead of spaces in the generated code. Note that since v0.5.0, the indent is auto-detected if you have a by a EditorConfig file
• renameLibs = "Deps" to generate Deps.kt instead of Libs.kt
• renameVersions = "V" to generate V.kt instead of Versions.kt
• useFqdnFor("mail", "annotations", "androidx.persistence.room", "androidx.persistence"). Using Libs.annotations may not make sense out of context. With this config it will be Libs.com_example_group_annotations. Some MEANING_LESS_NAMES like "library" or "compiler" are pre-configured.

Which versions to reject?

Use your custom rejectVersionIf { ... }

rejectVersionIf {
    isStable(currentVersion) && isNonStable(candidate.version)
}

You can even define your own function isNonStable() if the default one does not work for your project.

versionsOnlyMode

The plugin has since v0.5.0 a versionsOnlyMode for single-module Gradle projects. This is what powers the task :refreshVersions introduced in version v0.6.0

// build.gradle.kts
buildSrcVersions {
   versionsOnlyMode = VersionsOnlyMode.GRADLE_PROPERTIES
   versionsOnlyFile = "build.gradle"
}

versionsOnlyMode is an enum:

• KOTLIN_VAL will generate val okhttp = "3.2.0"
• KOTLIN_OBJECT will generate the same file as Versions.kt in the default mode
• GROOVY_DEF will generate def okhttp = '3.2.0'
• GROOVY_EXT will generate ext { okhttp = '3.2.0' }
• GRADLE_PROPERTIES will generate okhttp=3.2.0

Migration // Deprecation

Breaking changes:

Those configurations were marked as deprecated in 0.5.0 and removed in 0.6.0

buildSrcVersions {
    useFdqnFor = ... // typo, use useFqdnFor()
    useFdqnFor(...)  // typo, use useFqdnFor()
    rejectedVersionKeywords = ... // use rejectVersionIf { ... }
    rejectedVersionKeywords(...)  // use rejectVersionIf { ... }
}

Note for contributors:

New features should probably be an opt-in. If you do this, add a property to BuildSrcVersionsExtension, use it in the samples, document the default value in the README and with more details in this issue.

Test with Gradle 5.0

distributionUrl=https\://services.gradle.org/distributions/gradle-5.0-rc-1-all.zip

https://docs.gradle.org/release-nightly/userguide/upgrading_version_4.html

Customize the names "Versions" and "Libs"?

A frequent request I get is to customize the names Libs.kt and Versions.kt

I could add an option do do this:

buildSrcVersions {
    renameLibs = "Deps"
    renameVersions = "Versions"
}

If you are interested with that feature, can you tell more about your use case?

One use case I've noticed is that people have used buildSrc/src/main/kotlin/Deps.kt before using my plugin. So they have Deps.retrofit everywhere and it would be nice if they didn't have to change it. Unfortunately that wouldn't be very useful because it would be a wonder if they choose exactly the same name configuration that I did for all dependencies.

allow to configure repositories for syncLibs

We use a setup where our build can only uses artifacts from our in-house artifactory repository (basically a means to control what our developers are allowed to use). However, for "syncLibs" to work it needs access to external repos. Right now I slove that by manually adding "jcenter()" to "build.gradle" before running "syncLibs" (and then reverting that change again).

What would be really cool would be if I instead could configure "syncLibs" to use "jcenter" (or "mavenCentral" or other repos) in addition to the normal repositories.

Libs name changing when updated

When I run buildSrcVersions to update my Libs sometimes certain Libs will change their names and break Gradle sync. This seems to happen most often with the Kotlin standard library, but has also happened with Dagger.

The Kotlin standard library jumps between kotlin_stdlib_jdk8 and org_jetbrains_kotlin_kotlin_stdlib_jdk8.

while Dagger will sometimes add com_google as a prefix.

dagger -> com_google_dagger
dagger_compiler ->com_google_dagger_compiler

Task to update the versions one by one

Thanks for the PR on http4k - looks like it will be super useful. But now that I'm manually updating (some) dependencies, I'd really like a way in which I could update them in an interactive way without manually copying the strings.

I'd imagine running a gradle task which asks me (one-by-one) if I'd like to upgrade an out-of-date dependency from the old version to the new. Maybe with an option to just "accept all updates". This would then regenerate the source file containing the versions.

why this creates a settings.gradle file inside buildSrc folder?

why this plugin creates a settings.gradle file inside buildSrc folder?

[suggestion] Generate `Projects.kt` file with all subprojects

I love using this plugin to manage external dependencies, but when setting up intra-project dependencies amongst subprojects of a single repo, I have to resort to using Stringly-typed values again with implementation(project(":...")). It would be really nice if this plugin could generate a solution for this problem as well.

My proposal is to generate a 3rd file, Projects.kt, and in it generate functions for referencing each Gradle subproject as a dependency. It would be especially nice if this file used nested objects to make it easier to reference.

I just hand-wrote this kind of file for my own project, and it seems to be working really well. Makes setting up and referencing my subprojects/groups of subprojects much easier, and it would be awesome to have this file generated automatically. The links below show sample usage of what this could look like, but I just threw this together and am open to any suggestions for better structure.

• Projects.kt
• Auto-register subprojects in settings.gradle
• Setup dependency on single project
• Setup dependency on an entire group of projects

Improve README

• Clarification: it's not about rewriting your build files to Kotlin, it's about moving the build logic to the buildSrc module and using Kotlin there
  android/sunflower#218 (comment)

Proposed next steps

• Config object
• Project.kt pattern
• Converting a complete project rozkminiacz/KotlinUnitTesting#2

Dependency has no version

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

Some plugins like io.vertx.vertx-plugin pin a dependency version. In that case, buildSrcVersions generate the following code

// sample-groovy/build.gradle
plugins {
    id "io.vertx.vertx-plugin" version "0.3.1"
    id 'de.fayard.buildSrcVersions' version '0.4.0'
}
dependencies {
    implementation "io.vertx:vertx-web"
}

// Libs.kt
object Libs {
    const val vertx_core: String = "io.vertx:vertx-core"
}
// Versions.kt
object Versions {
    const val vertx_core: String = "none" // No version. See buildSrcVersions#23
} 

What follows is the problem that appears in version 0.3.2 and before in that case

---

Hello,

I have to say that this plugin is really cool and helpful! :)

However, I have found a few issues related to reporting of release versions, and I couldn't find anyone else posting about it, so I am adding this new issue.

I have a simple Spring Boot, reactive, restful web service, that I created using Spring Initializr a few weeks ago. I have properly configured my project and the Gradle-Kotin-Dsl-Libs ("GKDL"), and it generates the Libs and Versions files, as expected. However, the version information for the following items is incorrect, since it does not match the versions that I started with, nor what Spring Initializr generates. I've noticed that these issues appear in the first and the last two entries in the Libs file that is generated. Has anyone noticed this issue? If I can provide any more information, please let me know...

Thank you for your time,

Mike

---

• org_springframework_cloud:
  Versions => "2.1.0.RELEASE";
  Should be "Greenwich.BUILD-SNAPSHOT";

• spring_boot_starter_webflux:
  Versions => "none";
  Should be "2.1.0.RELEASE";

• jackson_module_kotlin:
  Versions => "none";
  Should be "2.9.7";

VERSION INFORMATION
IntelliJ: 2018.2.6
Java: 11.0.1
Kotlin: 1.3.10
Kotlin DSL: 1.0.4
Gradle: 5.0
Shadow: 4.0.2
Gradle-Kotin-Dsl-Libs: 0.2.6
Spring Boot: 2.1.0.RELEASE
Spring Cloud: 2.1.0.RELEASE, but should be Greenwich.BUILD-SNAPSHOT

Files.zip

Meaningless variable names

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.

How to add new dependencies?

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

The description shows how to bootstrap the switch and how to update to new dependencies. However, I can't see how to add a new dependency. Looks to me that Libs.kt is not meant to be manually edited. So is the idea to add an "old-fashioned" dependency, and then run syncLibs to create a new Libs.kt, and then replace the dependency literal? That feels convoluted. Is there a better way? Perhaps a registerDependency task that takes a dependency string and adds it to Libs.kt and Versions.kt?

Version strange from JitPack.io

I published my own lib on JitPack: https://jitpack.io/#IgorGanapolsky/seekarc/v1.2.0
In my gradle file am importing it as follows:
implementation 'com.github.IgorGanapolsky:SeekArc:v1.2.0'

However, your plugin states:

// available: "1.2"

Can you please advise of the correct behavior?

New project name: gradle buildSrcVersions

Context: buildSrcVersions is a Gradle plugin that makes it easier to manage your dependencies inside your IDE. It extracts all your dependencies and search for available dependencies updates.

I decided I don't want to be stuck with a bad naming for-ever and that I should better do it now than later.

Renaming

• The repo is now https://github.com/jmfayard/buildSrcVersions
• The plugin is now called buildSrcVersions
• The task to run is: $./gradlew buildSrcVersions
• The extension is now buildSrcVersions { ... }

Update

Juste update the block: plugins { }

plugins {
  id("de.fayard.buildSrcVersions") version $gradlePluginPortalVersion
  // id("jmfayard.github.io.gradle-kotlin-dsl-libs") version "0.2.6"
}

Before the renaming

• The repo will be jmfayard/gradle-kotlin-dsl-libs
• Install with plugins { id("jmfayard.github.io.gradle-kotlin-dsl-libs") }
• Run with: $./gradlew syncLibs

Reasons for the change

There are only two hard things in Computer Science:
cache invalidation and naming things.
-- Phil Karlton

• buildSrcVersions tells what the plugin does: re-generate buildSrc/.../Versions.kt. Neither syncLibs nor gradle-kotlin-dsl-libs does that 😞 .
• 😞 syncLibs is way too generic.
• 😞 Libs insists on the wrong thing. Extracting Libs.xxx is done once, searching for new Versions is done many times and is more valuable.
• 😞 No consistency between syncLibs and gradle-kotlin-dsl-libs.
• 😞 gradle-kotlin-dsl-libs is not exactly easy to understand and remember. Heck, even I didn't remember it.
• 😞 It gives the wrong impression that it requires the Kotlin DSL. Something people usually don't know about yet, let alone have upgraded their builds.

TODOs

• Rename the repo
• Publishing to the gradlePluginPortal the plugin de.fayard.buildSrcVersions version 0.2.6 #27
• Thank you. Your new plugin de.fayard.buildSrcVersions has been submitted for approval by Gradle engineers. The request should be processed within the next 24 hours, at which point you will be contacted via email.
• Redo the README
• Document how to migrate here and in the CHANGELOG.
• Edit my previous articles to use the right pluginId.
• Add a warning in the current version of the plugin to warn of the migration.
• Do a Github Code search and warn my early adapters of the renaming.

Add dependency description in the kdoc

Proposed here
ben-manes/gradle-versions-plugin#266

Order dependencies by group

Given the following dependencies

dependencies {
  val room_version = "1.1.1"
  compile("android.arch.persistence.room:runtime:$room_version")
  compile("android.arch.persistence.room:compiler:$room_version" )
  compile("android.arch.persistence.room:rxjava2:$room_version")
}

Since those dependencies are grouped together and especially the versions should be coherent, it would be much nicer if they were grouped together.

=> sort dependencies by group, not by name

Configuring plugins versions

To apply a plugin, we can use the plugins DSL https://docs.gradle.org/current/userguide/plugins.html#sec:plugins_block

plugins {
  id 'com.github.jk1.dependency-license-report' version '1.9'
}

The problem is replacing the hard-coded version 1.9 with Versions.gradle_license_report does not work for Groovy files.

Is there a workaround to be able to use buildSrcVersions for managing plugin dependencies as well as Library dependencies?

This is already done for the special case of buildSrcVersions itself (#47) , although that only works in .kts files.

plugins {
-  id("de.fayard.buildSrcVersions") version "0.4.2"
+ buildSrcVersions
}

import kotlin.String necessary?

Since 4.0.2 an import to kotlin.String is created in the Versions.kt.
I am not sure but suspect, that this import is redundant. So maybe skip it?

`./gradlew buildSrcVersions` produces a stack overflow

Hi,

I use this fabulous plugin in our internal builds. However, for one of our projects it does not work and instead produces a stack overflow. I reduced that project to the bare minimum and ended up with a simple build file containing 2 jars as dependencies. The tricky part is that we have a local repo containing a modified version of one of the jars. Thus, the attached project is not executable for you. However, I added the log file from a ./gradlew --debug buildSrcVersions > gradle.log 2>&1 which shows the stack overflow.

stackoverflow.zip

Add buildSrc/.gitignore

Add buildSrc/.gitignore to make sure the build does not get added to the repo

Support different code style

I am using two spaces indentation. The autogenerated file uses 4 spaces.
Whenever I am editing and committing the versions file, everything has changes.

I would love to be able to configure the code style (or maybe pick it up from the .editorconfig file?)

Request: Do not generate (or at least have an option to disable) superfluous comments

It would be great to ditch the "up-to-date" messages. Kind of feels like superfluous info.

Also, if there could be an option not to generate the website information in the plugin, that would be ace.

thanks :)

Detect when multiple dependencies from the same group use the same version

A common pattern is to use something like this

dependencies {
    val kotlinVersion = "1.2.71"
    compile("org.jetbrains.kotlin:kotlin-stdlib-common:${kotlinVersion}")
    compile("org.jetbrains.kotlin:kotlin-test-common:${kotlinVersion}")
    compile("org.jetbrains.kotlin:kotlin-test-annotations-common:${kotlinVersion}")
}

We could emulate that in the output of buildSrc/src/main/kotlin/Versions.kt

• IF multiple dependencies belong to the same group
• AND IF they all have the exact same version
• then define a single version like

object Versions {
     const val org_jetbrains_kotlin = "1.2.71"
}