You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The crate-local Maven repository didn't work for Signal because we use rustls-platform-verifier in a library, and our main app doesn't know about Rust at all. We determined that as long as no other library is using rustls-platform-verifier, and as long as rustls-platform-verifier's Java/Kotlin side doesn't need anything but its classes, we can slurp those classes into our library directly and everything will be fine. (And indeed, it is working for us.)
This may have some downsides for general use (the main one being that files(…) dependencies can't have metadata), but given how minimal the crate-local Maven repository is, I'm not sure they'll come up in practice. So maybe this is a simpler approach for future versions of the crate?
We're also running into this issue as we distribute an android library and the consumers have understandably difficulties resolving rustls:rustls-platform-verifier:latest.release. Most likely we'll follow a similar path to above and ship the library bundled.
We've run into some issues related to rustls-platform-verifier
distributing an android library through their crate, which works great
if you use platform-verifier within an application. However since we
distribute an sdk, the application have difficulties locating the
android specific platform-verifier library.
To resolve this we follow the method established in
rustls/rustls-platform-verifier#115 and bundle
the classes with the library.
The crate-local Maven repository didn't work for Signal because we use rustls-platform-verifier in a library, and our main app doesn't know about Rust at all. We determined that as long as no other library is using rustls-platform-verifier, and as long as rustls-platform-verifier's Java/Kotlin side doesn't need anything but its classes, we can slurp those classes into our library directly and everything will be fine. (And indeed, it is working for us.)
This may have some downsides for general use (the main one being that
files(…)
dependencies can't have metadata), but given how minimal the crate-local Maven repository is, I'm not sure they'll come up in practice. So maybe this is a simpler approach for future versions of the crate?The text was updated successfully, but these errors were encountered: