Long term plan: focus on refreshVersions

[jmfayard]

The long-term plan for v1.0 is to focus on :refreshVersions instead of :buildSrcVersions

refreshVersions

Starting from release 0.8.0 the plugin is now called and contain only the task refreshVersions

plugins {
  id("de.fayard.refreshVersions").version("0.8.x") // or newer
}

buildSrcVersions

We are not quite ready yet to extract the useful parts of buildSrcVersions to another plugin, so if you need the features from buildSrcVersions, stay with this for now:

plugins {
  id("de.fayard.buildSrcVersions").version("0.7.0")
}

Next step

The file buildSrc/src/main/Libs.kt is still useful right now, but I am working on a better solution in collaboration with this project

https://github.com/LouisCAD/Splitties

Later plans

• rename the project, making sure that the URLs still work
• rename the extension name from buildSrcVersions { ... } to refreshVersions { ... }
• have a minimialist plugin that focus on :refreshVersions
• keep the plugin buildSrcVersions for my existing users who need their current features

[DanySK]

Hi,
I'm planning to work on either a dependabot module or a new bot supporting the generation of PR on available dependency updates for projects using buildSrcVersions.
My plan would be to support only buildSrcVersions, and not refreshVersions, at least initially, as I find having to fetch properties much worse than having compile-time dependencies towards an entry in a generated kt file.

My question is: I read that you plan to still support buildSrcVersions, which is great. Do you plan to change the syntax of Versions.kt? Will the file still get generated in future versions?

[LouisCAD]

Hi @DanySK, buildSrcVersions is being replaced by refreshVersions for 3 main reasons:

1. Editing the content of the buildSrc invalidates the whole build, defeating all the caches. This has a negative impact on the productivity of the users as they wait longer for gradle tasks to execute.
2. Generating a "neat" code is not trivial. We found that it's easier to write it by hand, and updating the versions separately.
3. Grouping of artifacts (with synchronized versions) has conflicting conventions that need a case by case handling.

Consequently, this project is going to focus on updating the versions of the dependencies, and the structure will be split in two parts:

• One will be provided by the upcoming Splitties Gradle plugin for popular dependencies (Kotlin, kotlinx, AndroidX, Square/Cashapp, junit, etc)
• The rest will be written manually by the users in their own buildSrc, using a version placeholder (we settled on _) so the future version of this plugin can still provide updates.

Our goal for this plugin is to provide good defaults as well as a properly defined configurability so the new versions can be easily discovered with human readable versions.properties file. Increasing the speed of the refreshVersions task is also in the plans.

For the Splitties plugin, it is to make the build.gradle.kts scripts more readable as to which dependencies are used, and auto-complete ready.

I hope it now makes sense to you and that you no longer find the planned future behavior "much worse".

In the meantime, while we're preparing and testing the upcoming versions of the two Gradle plugins, I recommend you to keep using the version that supports buildSrcVersions.

We will provide updates in this issue as we make progress on these two Gradle plugins.

[jmfayard]

See also is buildSrcVersions gone? #119

What is true is that the two plugins are not identical aymore.
I edited the description of the issue to reflect this.

[nkiesel]

I use Versions outside of Libs, namely in settings.gradle for defining Gradle plugin versions:

    plugins {
	id "com.gradle.build-scan" version Versions.com_gradle_build_scan_gradle_plugin
	id "org.sonarqube" version Versions.org_sonarqube_gradle_plugin
	id "de.fayard.buildSrcVersions" version Versions.de_fayard_buildsrcversions_gradle_plugin
    }

How will this work (ideally preserving the nice IDE completion of version names) with the grand new plan which - as I understand it - will no longer have a Versions object?

[jmfayard]

@nkiesel the plugins version will be set in the file versions.properties by a property like plugin.de.fayard.refreshVersions=1.0.0 or generally plugin.$PLUGIN=$VERSION

[nkiesel]

I understand how the version.properties file looks like, and I can see how you would build the Libs.kt using this property file. But how would that look for mysettings.gradle? Something like

id "de.fayard.buildSrcVersions" version versions.get["de_fayard_buildsrcversions_gradle_plugin"]

Will Gradle know that this versions.propertiesfile exists, or do I now have to add custom code to read that file (and is that even possible at that place in settings.gradle)?

[jmfayard]

You would declare the plugins without the version.

plugins {
id("de.fayard.buildSrcVersions")
}

How exactly gradle recognize the versions file is not finalized yet. Currently it's a one liner to include an utility file inside settings.gradle

[DanySK]

Hi @LouisCAD and @jmfayard,
thanks for the explanation.

My "much worse" is referred to my use cases (often large projects), and limited to the comparison between using buildSrcVersions alone vs. using refreshVersions alone, and it does not take into account other in-development plugins.

The main drawback that keeps me from switching is to have to give up the nice compile time reference to the library and the somewhat cumbersome way the Kotlin DSL for gradle uses to access properties:

implementation(Libs.something)

vs

implementation("group:artifact${${project.extra["group.artifact.version"]}}

If I understand correctly, there will be some way to rebuild the former based on a plugin which is now in-development.

Is there a preview of how the build.gradle.kts and other build files (besides version.properties) will look like?
For instance, it's unclear to me right now the role of _.
Thanks

[jmfayard]

@DanySK
just to be clear, no need to migrate now, we are not quite ready yet.

I have a sample project that shows the new system here
https://github.com/jmfayard/update-legacy-android-project

You won't need to use manually project.extra, the dependencies versions are overridden globally and automatically when they are present.

To make Android studio happy, you just need an initial version which can be either 1.0.0 or + or _. Android Sync is not happy with it so we will probably use + but the idea remains that this placeholder version is not used.

You can still define the dependencies (with a placeholder version) in a separate file like Libs.kt .
The common dependencies that a lot of people are using like AndroidX or unit testing or square will be predefined in the Splitties plug-in

[DanySK]

I'm not very much concerned about Android Studio or IntelliJ or any specific IDE.
I took a look to the project you linked. Looks like it's changing the way plugin dependencies are resolved, implicitly reading from the property file.
I imagine something similar will be provided for non-plugin dependencies, am I right? So will the look of it be similar to:

dependencies {
    // module referenced by plugin, version by property file
    implementation(Libs.veryCommonAndroidLibrary)
    implementation("group:artifact") // Version auto-loaded from property file
}

Correct?

Sorry for the many questions, I'm not in hurry to migrate, but I'd like to understand the system as soon as possible, as I may adopt it early and possibly provide some feedback or suggestions: the plugin is useful, so helping evolving it may have positive feedback on my projects as well.

Also, in case I find time to develop a dependabot extension for gradle builds using your plugin, I'd like to focus where the project is focused, rather than investing time in supporting a deprecated product :)

[jmfayard]

@DanySK you are exactly correct.
In fact it should be enough to rerun$ ./gradlew --update refreshVersions to have the updated versions.properties file being generated, plus whatever magic is needed to create the GitHub pull requests etc...

[DanySK]

I'll likely need to do some manual parsing in order to generate one PR per update, but looks neat.
Thanks, looking forward for the plugin infrastructure to get released!

[LouisCAD]

Taking back from your example, @DanySK:

implementation("group:artifact") // Version auto-loaded from property file

it's more likely that it'd not work unless the version placeholder (appending :_) is used. That allows to not clash with platform (maven BoM) dependencies and similar version resolutions set by other gradle plugins (like the Kotlin one).

Dependencies declared in constants from buildSrc or gradle plugins like the Splitties one would have _ as their version to be marked as getting their version from versions.properties.

This is where I'm headed (experimenting with the new updater), but things might change before we settle the behavior.

[DanySK]

Thanks. So the prospected look of it would be something like:

implementation("group:artifact:_") // Version auto-loaded from property file

Looks fine as well, not much of a change.

Would it make sense in your opinion to create an automatically maintained separate library / plugin which scans the most common repositories (Central, JCenter, Jitpack, Gradle plugin portal, etc) and provides names as variables?
Basically doing the work Libs.kt does now, but automatically and on whole repositories? Something like:

implementation(${com_google.guava}:_) // returns the string com:google:guava, but can be looked up in the IDE

[jmfayard]

@DanySK Yes, that's the plugin com.louiscad.splitties plugin that we are working on here
https://github.com/LouisCAD/Splitties/tree/develop/plugin/src/main/kotlin/com/louiscad/splitties

This plugin is for Android dependencies.
I think I will do later a plugin for backend/JVM libraries later

[LouisCAD]

Actually, Splitties is moving to be a multiplatform project (although the biggest work I did there hasn't made it to a non dev release yet), so I'd make the plugin not target just Android in the near future.

That said, it might make sense to have a backend focused plugin for the popular dependency constants, which might or might not be in Splitties.