Meet SDK for Android fails after React Native upgrade to 0.55.4


#1

Recently, the React Native dependency of Meet was updated to 0.55.4. This causes projects that make use of the Android SDK to fail.

The Android SDK does not pin the version of its React Native dependency.

React Native dependencies are not available in a public repository, other than Jitsi’s own repository.

Jitsi’s own repository does currently not include version 0.55.4 or the React Native artifact.

Could all third-party dependencies of the Android SDK be published please?

The Android SDK dependencies remain a bit of a floating target, making it hard for projects to work with it. I’m not sure if version pinning would help, but it would be great if continuous integration could detect and prevent problems with the availability of dependencies.


#2

Additionally, when trying to follow the instructions to build and publish third party dependencies locally, I failed to make available the react-native 0.55.4 artifact myself.

$ ./gradlew :react-native:assembleRelease

> Configure project :app
Configuration 'compile' in project ':app' is deprecated. Use 'implementation' instead.

> Configure project :react-native-background-timer
Configuration 'compile' in project ':react-native-background-timer' is deprecated. Use 'implementation' instead.

> Configure project :react-native-calendar-events
Configuration 'compile' in project ':react-native-calendar-events' is deprecated. Use 'implementation' instead.

> Configure project :react-native-fetch-blob
Configuration 'compile' in project ':react-native-fetch-blob' is deprecated. Use 'implementation' instead.

> Configure project :react-native-immersive
Configuration 'compile' in project ':react-native-immersive' is deprecated. Use 'implementation' instead.

> Configure project :react-native-keep-awake
Configuration 'compile' in project ':react-native-keep-awake' is deprecated. Use 'implementation' instead.

> Configure project :react-native-locale-detector
Configuration 'compile' in project ':react-native-locale-detector' is deprecated. Use 'implementation' instead.

> Configure project :react-native-sound
Configuration 'compile' in project ':react-native-sound' is deprecated. Use 'implementation' instead.

> Configure project :react-native-vector-icons
Configuration 'compile' in project ':react-native-vector-icons' is deprecated. Use 'implementation' instead.

> Configure project :react-native-webrtc
Configuration 'compile' in project ':react-native-webrtc' is deprecated. Use 'implementation' instead.

> Configure project :sdk
Configuration 'compile' in project ':sdk' is deprecated. Use 'implementation' instead.
Configuration 'testCompile' in project ':sdk' is deprecated. Use 'testImplementation' instead.


FAILURE: Build failed with an exception.

* What went wrong:
Project 'react-native' is ambiguous in root project 'jitsi-meet'. Candidates are: 'react-native-background-timer', 'react-native-calendar-events', 'react-native-fetch-blob', 'react-native-immersive', 'react-native-keep-awake', 'react-native-locale-detector', 'react-native-sound', 'react-native-vector-icons', 'react-native-webrtc'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 0s

#3

The artifact for current version for the react-native-calendar-events dependency, 1.6.0-jitsi-1, isn’t in the repo either. That’s easily fixed by building it locally of course, but ideally, these should be available.


#4

For posterity: the binary artifacts for react-native can be copied from node_modules into your local maven repository, after you do npm -i on the meet project. The artifacts are found in jitsi-meet/node_modules/react-native/android/com. You’ll need to copy them into your local maven repository like this:

cp -r /path/to/jitsi-meet/node_modules/react-native/android/com /path/to/myrepo/

#5

The Android SDK does not pin the version of its React Native dependency.

At the source code level, the RN version is pinned by package.json. At the binary level, the RN version is pinned by the .pom file deployed with that binary.

React Native dependencies are not available in a public repository, other than Jitsi’s own repository.

After npm install, the RN Maven artifact is in node_modules/react-native. We just deploy it to our github:jitsi/jitsi-maven-repository to reference it in the SDK .pom file.

I’m not really sure whether you’re talking about the RN artifact itself or the artifacts of our third-party react-native dependencies such as react-native-fetch-blob, etc:

These are again installed with the above npm install and then we issue ./gradlew :react-native-fetch-blob:assembleRelease followed by ./gradlew :react-native-fetch-blob:publish. Again their origin and version are pinned/locked by package.json and package-lock.json.

Jitsi’s own repository does currently not include version 0.55.4 or the React Native artifact.

Correct. We deploy the RN artifact from node_modules/react-native only when we reference it in a .pom file. There’s currently no such .pom file at github:jitsi/jitsi-maven-repository.

Could all third-party dependencies of the Android SDK be published please?

I’m afraid I’m not really sure what is left to be published. The binaries we publish stem from the SDK binary and what its .pom references. We don’t publish dependency binaries unless they are referenced by a SDK .pom. So in the timeframe between the last SDK release and current development third-party dependencies may be upgraded in dev but will no binaries will be published because no SDK .pom will reference them.

The Android SDK dependencies remain a bit of a floating target, making it hard for projects to work with it. I’m not sure if version pinning would help, but it would be great if continuous integration could detect and prevent problems with the availability of dependencies.

You should not be mixing source and binary versions. In source code form, the Android SDK dependencies are locked/pinned by package.json and package-lock.json. In binary form, the Android SDK dependencies are pinned by the SDK’s published .pom file. I’m afraid I don’t fully understand your requirement here.


#6

./gradlew :react-native:assembleRelease

No. The react-native binary artifact is available in node_modules/react-native (more specifically, node_modules/react-native/android/com/facebook/react/react-native/) after you do npm install in the jitsi-meet.


#7

The artifact for current version for the react-native-calendar-events dependency, 1.6.0-jitsi-1, isn’t in the repo either. That’s easily fixed by building it locally of course, but ideally, these should be available.

There’s no SDK .pom file referencing 1.6.0-jitsi-1, right? That’s why we never deployed such an artifact version. The last SDK .pom file references 1.5.0-jitsi-1 which in accord with the respective package.json and package-lock.json is “dabfabc4bacc1424a8b93ebdda6f3820dee198cb + react-native 0.51”.

Again in the time between two binary releases of the SDK, there’s a development period during which we don’t make “nightly” SDK binaries and its binary dependencies available. During that period, binaries of these can be produced from source because they’re not final according to us anyway (as we’re in a development period).


#9

A great deal of confusion is introduced (my bad) by me trying to make use of the current master tip, not the released binary SDK (I need a couple of additional fixes that are in trunk, but not in the published binary artifacts, as well as some additional, custom modifications). But, as the tip of master also introduces a new, unrelated issue (I’m not able to use the camera on a device that has no user-facing camera for some reason), I’ll drop what I have now, and start over with an older release.

Apologies for the confusion. It has been a long day…


#10

I’m not able to use the camera on a device that has no user-facing camera for some reason

It may be beneficial (I guess) to discuss this issue in a separate thread. I don’t know that we have devices without user-facing cameras on hand so that thread may take some back and forth of its own to figure out.


#11