1347973 - [geckoview] Publish GeckoView builds on jcenter

Status: RESOLVED DUPLICATE of bug 1433198

(GeckoView :: General, enhancement)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

This will allow a very easy to consume GeckoView via Android Studio.

Comment 1

[Nick Alexander :nalexander [he/him]]

I can think of the following things that will need to happen to publish:

- we'll need to version the GV library, around https://dxr.mozilla.org/mozilla-central/source/mobile/android/geckoview/build.gradle#13.  The "easy" way to do this is to use the ANDROID_VERSION_CODE mechanism we cobbled into place for Fennec, but it's very complicated (!) and completely unintuitive.  I'd much prefer it if we could find a way to produce per-channel library versions (flavours?) and version each of those libraries independently, and with a more sensible version -- 5200 for Release and Beta, maybe ANDROID_VERSION_CODE for Aurora and Nightly.

- we'll need to choose a Gradle distribution approach.  I used the "maven" plugin to publish to a directory, and that might be enough to publish to one of the public repositories (like jcenter).  I see that ExoPlayer is using "bintray-release", which I think is very common: https://github.com/google/ExoPlayer/blob/release-v2/library/build.gradle#L17.

- we'll need to find a way to get credentials allocated, get them managed by releng, and get them provisioned to build (or distribution) machines.  This raises questions about signing or otherwise authenticating the library builds produced, and about whether the credentials should be different for Release/Beta and Aurora/Nightly.

- we should consider making this a separate Task Cluster task, consuming successful builds, perhaps running on its own schedule.  This might be better than gluing an external network dependency into the already complex build process.

Lots of these issues collapse and simplify if we assume we'll only publish Nightly GV libraries for the foreseeable future.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Nick Alexander :nalexander from comment #1)
> Lots of these issues collapse and simplify if we assume we'll only publish
> Nightly GV libraries for the foreseeable future.

I think that's a safe assumption. If we do anything more than that it will simply be to release a snapshot of m-c as a "stable" release, like most other projects do.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to Nick Alexander :nalexander from comment #1)
> - we'll need to version the GV library, around
> https://dxr.mozilla.org/mozilla-central/source/mobile/android/geckoview/
> build.gradle#13.  The "easy" way to do this is to use the
> ANDROID_VERSION_CODE mechanism we cobbled into place for Fennec, but it's
> very complicated (!) and completely unintuitive.  I'd much prefer it if we
> could find a way to produce per-channel library versions (flavours?) and
> version each of those libraries independently, and with a more sensible
> version -- 5200 for Release and Beta, maybe ANDROID_VERSION_CODE for Aurora
> and Nightly.

I'm unfamiliar with the versioning conventions for Android libraries, but I'd look for a way to distinguish between the GeckoView and Gecko versions, using something like semver for the former to identify milestones and breaking changes to the GeckoView API.

Other projects that embed a runtime dependency, like Electron and Node, do something similar: "electron --version" is independent of "electron --abi", and "node --version" is independent of "node -p process.versions.v8".

(I'm unsure of a good example on Android, but I see that Crosswalk uses both monotonically increasing numbers and a separate number that looks like it reflects the Android API level <https://crosswalk-project.org/documentation/apis/embedding_api.html>.)

Comment 4

[Chris Peterson [:cpeterson]]

catlee is working on publishing a GeckoView Maven repo to Bintray/JCenter in bug 1433198.