@Nikky Can you put this in a GitHub issue please? It's a bit easier to keep track of it that way.

Refresh versions couldn't find kotest deps (some sub-deps have different versioning than the main library...). How can I tell refresh-versions to manage the version for assertion and extentions separately?

Is it possible to define my own version aliases? 🙂 For instance when using spring, I would like to alias these to a single version property (

version.spring.boot

):

version.org.springframework.boot..spring-boot-actuator=2.4.5
version.org.springframework.boot..spring-boot-starter-test=2.4.5
version.org.springframework.boot..spring-boot-starter-webflux=2.4.5

When building

main

locally, I get these 2 failures. Anyone know why?

RefreshVersionsUpgradeMigrationTest > test removal of migration call for Gradle Groovy DSL() FAILED
    org.opentest4j.AssertionFailedError at RefreshVersionsUpgradeMigrationTest.kt:29

RefreshVersionsUpgradeMigrationTest > test removal of migration call for Gradle Kotlin DSL() FAILED
    org.opentest4j.AssertionFailedError at RefreshVersionsUpgradeMigrationTest.kt:19

Does refresh versions slow down my build at all? Starting a new project and my team lead wants to go with buildSrc, but I think we should try refresh versions, but he says refresh versions would have some sort of build speed impact too.

It seems like refreshVersions is using an older version of apache's HttpClient, since it's causing a clash with versions Google's Jib tool... it might be worth it to upgrade...

Hi! Starting 2-3 days ago, the

refreshVersions

task fails because of an HTTP 403. Can’t figure out which repo might be causing this or how to diagnose better. This is a snippet of what I get when running it with

--stacktrace

:

Caused by: retrofit2.HttpException: HTTP 403 Response.error()
	at de.fayard.refreshVersions.core.internal.MavenDependencyVersionsFetcherHttp.getXmlMetadataOrNull(MavenDependencyVersionsFetcherHttp.kt:44)
	at de.fayard.refreshVersions.core.internal.MavenDependencyVersionsFetcherHttp$getXmlMetadataOrNull$1.invokeSuspend(MavenDependencyVersionsFetcherHttp.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)
	at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:274)
	at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:84)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:59)
	at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:38)
	at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
	at de.fayard.refreshVersions.core.RefreshVersionsTask.taskActionRefreshVersions(RefreshVersionsTask.kt:58)
...

Also tried running with

--debug

and

--info

but I don’t see anything helpful (or maybe I’m missing something)

Are there any plans to support version ranges (e.g.

x.y.+

or

[x.y.z,)

) in refresh versions? Currently it seems to somewhat respect them, but still often returns older versions than applicable for a given version range.

Hello friends, we need your help! It used to be cumbersome to migrate an existing project to refreshVersions, and we are changing that. We just published refreshVersions 0.11.0 which contains a new task refreshVersionsMigrate It would be nice if you can test it out and provide feedback before we announce it. https://github.com/jmfayard/refreshVersions/discussions/396

Is it possible to somehow access versions declared in

versions.properties

from

build.gradle(.kts)

?

[SOLVED] Use hardcoded versions instead

The AndroidX dependencies are annoying because they don’t follow a coherent versioning. @jmfayard

---- https://github.com/jmfayard/refreshVersions/issues/403 tl;dr: the 

lifecycle-extensions

 was not found (intended), because using version of 

2.3.0

 in a same group (

androidx.lifecycle

) tusing https://maven.google.com/web/#androidx.lifecycle:lifecycle-extensions:2.3.0 (not found, unless points to: 

2.2.0

) https://maven.google.com/web/#androidx.lifecycle:lifecycle-livedata:2.3.0 Is it possible to define different versions inside a same group? A suggestion for keyword to search(?), looks like I’m might missed this important samples/examples in the docs 🙏

Is it possible to use

versionFor

inside a

buildscript { }

? https://github.com/jmfayard/refreshVersions/issues/407

None of the entries have an

## unused

comment coming after you run the

refreshVersions

task?

It would be nice to have a little writeup of the syntax and meaning of the rules files... to learn from deduction could take a bit more time for more people... also, can we have our own definitions of deps in buildSrc in the same way we would contribute? (Or maybe even have a seperate internal plugin for less-widely used libs -- that are used in our company?)

It looks like most of the time, refreshVersions uses rootDir.resolve("versions.properties") to resolve versionsPropertiesFiles, however line 82 of https://github.com/jmfayard/refreshVersions/blob/main/plugins/dependencies/src/main/kotlin/de/fayard/refreshVersions/RefreshVersionsPlugin.kt shows it using the value from the config file. Is there any reason that that same method of selecting the "versions.properties" file cannot be used elsewhere? I've been using the option of specifying the versionPropertiesFile in my settings.gradle.kt in order to have multiple included builds to use the same versions. I could also, symlink my 'master' versions.properties to the versions.properties in the root of each included build. which is the 'better' way?

Could this error be linked to running refreshVersions and migrate (on my CI build)?

* What went wrong:
74s
17	Could not resolve all artifacts for configuration 'classpath'.
74s
18	> Could not resolve gradle.plugin.com.google.cloud.tools:jib-gradle-plugin:3.1.1.
74s
19	  Required by:
74s
20	      unspecified:unspecified:unspecified > com.google.cloud.tools.jib:com.google.cloud.tools.jib.gradle.plugin:3.1.1
74s
21	   > Could not resolve gradle.plugin.com.google.cloud.tools:jib-gradle-plugin:3.1.1.
74s
22	      > Could not get resource '<https://plugins.gradle.org/m2/gradle/plugin/com/google/cloud/tools/jib-gradle-plugin/3.1.1/jib-gradle-plugin-3.1.1.pom>'.
74s
23	         > Could not GET '<https://plugins.gradle.org/m2/gradle/plugin/com/google/cloud/tools/jib-gradle-plugin/3.1.1/jib-gradle-plugin-3.1.1.pom>'. Received status code 500 from server: Internal Server Error
74s
24	> Could not resolve de.fayard.refreshVersions:refreshVersions:0.20.0.
74s
25	  Required by:
74s
26	      unspecified:unspecified:unspecified > de.fayard.refreshVersions:de.fayard.refreshVersions.gradle.plugin:0.20.0
74s
27	   > Skipped due to earlier error

Hey! First of all, thank you very much for the plugin, it's really the most fun and convenient way to manage dependency versions as of yet on my opinion. I have two jitpack-only libraries in the project.

./gradlew refreshVersions

currently fails for one of them. Looking through the logs I see that

maven-metadata.xml

is available for the chthai64/SwipeRevealLayout, but for amulyakhare/TextDrawable JitPack just returns 404. Do I understand correctly that this is strictly an issue with JitPack and has nothing to do with the plugin? If so, is there a way to ignore speicifc artifact when refreshing versions, but keep using version resolution for it (so I don't have to switch from

_

to pinning the version in

build.gradle

for this "broken" package)?

I think it would be nice with enforced sorting and sectioning in

versions.properties

to make it easier to navigate. Something like:

## Plugins (alphabetically sorted on substring after `plugin.`)
plugin.com.adarshr.test-logger=3.1.0

plugin.com.github.johnrengelman.shadow=7.1.0

plugin.org.jlleitschuh.gradle.ktlint=10.2.0


## Custom notations (alphabetically sorted on substring after `version.`)
version.kotest=4.6.3

version.kotlin=1.6.0

version.ktor=1.5.3


## Generated identifiers (alphabetically sorted on substring after `version.`)
version.org.mock-server..mockserver-core=5.11.2

version.org.postgresql..postgresql=42.3.1

What do you think?

We support defining the versions file, which allows you to share it with multiple projects. You'll only have irrelevant "unused" comments appear after running refreshVersions, and you'll want to run it from each project.

Funny... why is refreshVersions failing at the end with:

<-- HTTP FAILED: okhttp3.internal.http2.StreamResetException: stream was reset: CANCEL
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
--> GET <https://dl.google.com/dl/android/maven2/androidx/lifecycle/lifecycle-service/maven-metadata.xml>
--> GET <https://dl.google.com/dl/android/maven2/androidx/lifecycle/lifecycle-livedata-ktx/maven-metadata.xml>
--> GET <https://dl.google.com/dl/android/maven2/com/squareup/moshi/moshi-kotlin-codegen/maven-metadata.xml>
<-- HTTP FAILED: java.io.IOException: Canceled
--> GET <https://dl.google.com/dl/android/maven2/androidx/lifecycle/lifecycle-runtime-ktx/maven-metadata.xml>
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
--> GET <https://dl.google.com/dl/android/maven2/io/kotest/extensions/kotest-extensions-wiremock/maven-metadata.xml>
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled
<-- HTTP FAILED: java.io.IOException: Canceled

Hello everyone. I recently added refreshVersion to my project. After executing the migrate task I facing some problems to sync the project. I see that the migrate task replaced the line `implementation("com.google.firebase:firebase-analytics:19.0.2")`by

implementation(Firebase.analytics)

and when goes to sync I get the following message :

Failed to resolve: com.google.firebase:firebase-analytics:

. Any idea to resolve that? If I came back with normal implementation of analytics the sync happens with success.

Just more question, I promise. Why do some implementation get with underline at end line? Like that

classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:_")

Keep getting socket timeout when refreshVersions is fetching

<https://plugins.gradle.org/m2/de/fayard/refreshVersions/de.fayard.refreshVersions.gradle.plugin/maven-metadata.xml>

Opening it in browser also seems to generate issues, see screenshot in thread..

gradle started complaining about this line:

implementation(Testing.junit.api)

e: ...\build.gradle.kts:90:46: Function invocation 'api(...)' expected

i am using gradle 7.3.3 (7.3 also has this behaviour)

I'm getting:

Line 13:     kotlin("plugin.serialization") version versionFor(Kotlin.stdlib)
                                                      ^ Unresolved reference: versionFor

for:

kotlin("plugin.serialization") version versionFor(Kotlin.stdlib)

in my plugins block... I have an import for it on top...

By the way, it would be nice to be able to have the boxed declarations handle such versions that depend on something else's version automatically... kotlinx serialization's plugin is the same version as Kotlin version...

Hi everyone, i'm unable to update gradle plugin's version. since i can update the version in project build.gradle after running

./gradlew refreshVersionsMigrate

it's replaced by

Android.tools.build.gradlePlugin

with an outdated version.

@louiscad I tried the code in the thread and the

refreshVersions

task on the main project still updates the

versions.properties

in mylib instead of the one in the setting.gradle.kts's path in the main project... is there any workaround?

Hello friends, I've got news! I implemented support for versions catalog: - generating automatically

gradle/libs.versions.toml

- rewriting the files

build.gradle(.kts)

to use them - adding dependency updates in

gradle/libs.versions.toml

It's published in the snapshot version

"0.40.2-SNAPSHOT"

Have a look at the Testing? pargraph from the pull-request https://github.com/jmfayard/refreshVersions/pull/509