Accessibility-Test-Framework-for-Android icon indicating copy to clipboard operation
Accessibility-Test-Framework-for-Android copied to clipboard

Migrate to protobuf-javalite

Open Jacks0N23 opened this issue 2 years ago • 2 comments

I have firebase-perf and espresso-contrib (which has dependency on this library) in same classpath so gradle cannot build my project because of duplicate classes from com.google.protobuf:protobuf-lite (from this lib) and com.google.protobuf:protobuf-javalite (from firebase-perf)

Here is the issue why firebase-perf migrated to javalite

So after u update this lib espresso team also need post a new version with updated deps And after all @Sloy(or someone else from barista team) should update barista and then I'll can assemble my project :) (@Sloy I mention you because latest update(4.1.0) with updating espresso became breaking)

Jacks0N23 avatar Sep 21 '21 17:09 Jacks0N23

I would like to understand if this is something that will be prioritized, and when it will be prioritized with a fix released that Espresso can pull in, as I am facing a similar issue.

While I can build my project, my espresso tests fail:

java.lang.ExceptionInInitializerError
	at java.lang.Class.classForName(Native Method)
	at java.lang.Class.forName(Class.java:453)
	at java.lang.Class.forName(Class.java:378)
	at com.google.android.gms.internal.cast.zzlu.zzje(com.google.android.gms:play-services-cast@@19.0.0:1)
	at com.google.android.gms.internal.cast.zzlu.<clinit>(com.google.android.gms:play-services-cast@@19.0.0:10)
	at com.google.android.gms.internal.cast.zzlu.zzjf(com.google.android.gms:play-services-cast@@19.0.0:5)
	at com.google.android.gms.internal.cast.zznb.zzd(com.google.android.gms:play-services-cast@@19.0.0:28)
	at com.google.android.gms.internal.cast.zzoa.zze(com.google.android.gms:play-services-cast@@19.0.0:5)
	at com.google.android.gms.internal.cast.zzoa.zzp(com.google.android.gms:play-services-cast@@19.0.0:14)
	at com.google.android.gms.internal.cast.zzmc$zzb.zzjw(com.google.android.gms:play-services-cast@@19.0.0:18)
	at com.google.android.gms.internal.cast.zzmc$zzb.zzjy(com.google.android.gms:play-services-cast@@19.0.0:39)
	at com.google.android.gms.internal.cast.zzmc$zzb.zzjx(com.google.android.gms:play-services-cast@@19.0.0:21)
	at com.google.android.gms.internal.cast.zzmc$zzb.zzjz(com.google.android.gms:play-services-cast@@19.0.0:40)
	at com.google.android.gms.internal.cast.zzo.zzbd(com.google.android.gms:play-services-cast-framework@@19.0.0:103)
	at com.google.android.gms.internal.cast.zzn.run(Unknown Source:2)
	at android.os.Handler.handleCallback(Handler.java:873)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:193)
	at android.app.ActivityThread.main(ActivityThread.java:6669)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Caused by: java.lang.IllegalStateException: Unable to lookup extension field offset
	at com.google.protobuf.ExtensionSchemaFull.getExtensionsFieldOffset(ExtensionSchemaFull.java:52)
	at com.google.protobuf.ExtensionSchemaFull.<clinit>(ExtensionSchemaFull.java:45)
	... 22 more

I can get around the test startup failures by adding

configurations {
    forEach { configuration ->
        configuration.exclude(group = "com.google.protobuf", module = "protobuf-lite")
    }
}

However, with this startup workaround, we are uncertain of whether or not our checks will be broken.

Using Espresso to validate accessibility checks are important to us, so it would be good for us to feel confident in our "fix". We are also very much interested in updating to Espresso 3.4 since version 3.3 has a dependency on android.support, which requires us to continue using jetifier, and is not ideal.

kevinzetterstrom avatar Dec 01 '21 21:12 kevinzetterstrom

The real fix here is for this library to ship a jarjared version of protobuf (whichever version you choose) inside of this library. Adding it as a direct dependency directly without jarjaring causes classpath collisions through various flavors of protobuf available, additionally version upgrades are not safe because protobuf is not binary safe from version to version. All in all, having it as a dependencies causes a huge problem for any client that use protobuf or include a library that does.

liutikas avatar May 12 '22 23:05 liutikas

@caseyburkhardt can you help us, please?

Jacks0N23 avatar Oct 11 '22 13:10 Jacks0N23

Closed issue because now all dependencies are correct

Jacks0N23 avatar Feb 17 '23 08:02 Jacks0N23