Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refreshVersions plugin causes classpath issues when applied with wire plugin #707

Open
1 task done
mr3y-the-programmer opened this issue Oct 2, 2023 · 6 comments
Open
1 task done

Comments

@mr3y-the-programmer
Copy link
Contributor

🐛 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
@mr3y-the-programmer
Copy link
Contributor Author

mr3y-the-programmer commented Oct 2, 2023

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")
}

@LouisCAD
Copy link
Member

LouisCAD commented Oct 2, 2023

Do you know which okio versions are requested by both plugins?

@mr3y-the-programmer
Copy link
Contributor Author

mr3y-the-programmer commented Oct 2, 2023

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)

@LouisCAD
Copy link
Member

LouisCAD commented Oct 2, 2023

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.

@mr3y-the-programmer
Copy link
Contributor Author

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.

@LouisCAD
Copy link
Member

LouisCAD commented Oct 3, 2023

You're right, we should write the limitation, and also document versions catalog support better

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants