refreshVersions
refreshVersions copied to clipboard
refreshVersions plugin causes classpath issues when applied with wire plugin
- [x] I have read the guidelines for submitting issues
🐛 Describe the bug
It seems like refreshVersions plugin is incompatible with square/wire gradle plugin which makes it impossible to use them together in a single project without disabling one of them.
I've a project that is using refreshVersions plugin, when I tried to apply wire gradle plugin to my project and run gradle task gradlew generate[SourceSet]Protos(e.g generateCommonMainProtos), the task execution failed with java.lang.NoSuchMethodError saying it couldn't find okio.FileSystem okio.Okio.asResourceFileSystem(java.lang.ClassLoader) method that is used by wire internally here, I disabled refreshVersions plugin and I was able to run generateCommonMainProtos successfully.
⚠️ Current behavior
Running ./gradlew generateCommonMainProtos fails with NoSuchMethodError, stacktrace:
Caused by: java.lang.NoSuchMethodError: 'okio.FileSystem okio.Okio.asResourceFileSystem(java.lang.ClassLoader)'
at com.squareup.wire.schema.CoreLoader$resourceFileSystem$2.invoke(CoreLoader.kt:34)
at com.squareup.wire.schema.CoreLoader$resourceFileSystem$2.invoke(CoreLoader.kt:33)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at com.squareup.wire.schema.CoreLoader.getResourceFileSystem(CoreLoader.kt:33)
at com.squareup.wire.schema.CoreLoader.load(CoreLoader.kt:39)
at com.squareup.wire.schema.internal.CommonSchemaLoader.load(CommonSchemaLoader.kt:148)
at com.squareup.wire.schema.Linker.getFileLinker$wire_schema(Linker.kt:77)
at com.squareup.wire.schema.Linker.link(Linker.kt:99)
at com.squareup.wire.schema.internal.CommonSchemaLoader.loadSchema(CommonSchemaLoader.kt:103)
at com.squareup.wire.schema.SchemaLoader.loadSchema(SchemaLoader.kt:71)
at com.squareup.wire.schema.WireRun.execute$wire_schema(WireRun.kt:234)
at com.squareup.wire.schema.WireRun.execute(WireRun.kt:221)
at com.squareup.wire.gradle.WireTask.generateWireFiles(WireTask.kt:189)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
✅ Expected behavior
Running ./gradlew generateCommonMainProtos should complete successfully with kotlin/java models being generated for proto definitions.
💣 Steps to reproduce
I've a sample reproducer here https://github.com/mr3y-the-programmer/refreshVersions-bug, running ./gradlew generateCommonMainProtos on the main branch completes successfully, while running the task on with refreshVersions branch fails with the aforementioned error.
📱 Tech info
- refreshVersions version: 0.60.3
- wire gradle plugin version: 4.9.1
- Gradle version: 8.3
- OS: Windows 10
Follow up: (Workaround) adding okio dependency to the buildscript classpath right before applying refreshVersions plugin in settings.gradle.kts solves the issue as well:
// It is important to add this BEFORE plugins {...} section, otherwise the task would fail as usual.
buildscript {
dependencies {
classpath("com.squareup.okio:okio:3.6.0")
}
}
plugins {
id("de.fayard.refreshVersions")
}
Do you know which okio versions are requested by both plugins?
Wire 4.9.1 seems to bring 3.5.0 version of okio, while if I have wire plugin coordinates declared as follows in libs.versions.toml:
[plugins]
wire = "com.squareup.wire:_"
gradle sync fails and it looks like refreshVersions can't detect a version for it, (it doesn't add a new version in versions.properties, and even If I added that manually, it doesn't help also). so, I have to use the version explicitly in libs.versions.toml to be able to download it:
[plugins]
wire = "com.squareup.wire:4.9.1"
and if I added okio dependency explicitly in libs.versions.toml, refreshVersions downloads version 3.6.0 (latest release)
(FYI: asResourceFileSystem should be available from okio 3.3.0 and later)
There's no reason to use the version placeholder in libs.toml.versions now as we can update this version catalog FYI. Also, the version placeholder is not supported for the plugins DSL.
Good to know that version placeholder is not supported in plugins DSL, speaking of version placeholders for libraries, does this section in the documentation need updating?
Does that work well with refreshVersions? Yes, as long as you use the version placeholder (_).
If I understand correctly what you said, this looks like to be outdated.
You're right, we should write the limitation, and also document versions catalog support better