Right now, every GeckoView-consuming project brews some instructions about how to take an org.mozilla.geckoview:geckoview-nightly-$ARCH:$VERSION Maven dependency and substitute in the local GeckoView from a given topsrcdir/topobjdir. See, e.g., Focus and FirefoxReality.

This ticket tracks unifying that logic with a shared Gradle script in topsrcdir. This will both simplify the downstream consumers and provide a valuable touchpoint with which to communicate best practices as they evolve. In particular, this provides a functional bridge to Gradle composite builds.

rbarker: I notice that FirefoxReality supports:

a) paths to AARs, not just to Maven repositories. Do you only use this for local GeckoView AARs, i.e., that you built?. Or do you also download AARs and plug them in? The latter is not easy to support generically.

b) separate paths to ARM and x86 AARs. Do you ever actually use both of these at the same time? This doesn't really make sense if we make substitution "topsrcdir/topobjdir" centric, since you'll never get both ARM and x86 AARs from the topsrcdir.

This will require some changes to downstream consumers and many updated documents. Some of those I will handle myself and some I hope others will handle.

mcomella: eventually this might end up in a shared Gradle plugin -- just getting it onto your radar.

mcomella: fluffyemily: In the meantime, can you help me collect downstream consumers we should try to align on this approach? I'm aware of:

• firefox-tv
  [ ] Here's a PR: https://github.com/mozilla-mobile/firefox-tv/pull/1922
• reference-browser
  [ ] Here's a PR: https://github.com/mozilla-mobile/reference-browser/pull/871
• fenix
  [ ] Here's a PR: https://github.com/mozilla-mobile/fenix/pull/4761
• focus (has a wiki entry)
• android-components
• FirefoxReality (has a README entry)
  [ ] Here's a PR: https://github.com/MozillaReality/FirefoxReality/pull/988
• Firefox Send

Anybody else?

• Firefox Send - they're in the process of starting out with GV so they may be too early stage to be affected.

(In reply to Nick Alexander :nalexander [he/him] from comment #1)

rbarker: I notice that FirefoxReality supports:

a) paths to AARs, not just to Maven repositories. Do you only use this for local GeckoView AARs, i.e., that you built?. Or do you also download AARs and plug them in? The latter is not easy to support generically.

b) separate paths to ARM and x86 AARs. Do you ever actually use both of these at the same time? This doesn't really make sense if we make substitution "topsrcdir/topobjdir" centric, since you'll never get both ARM and x86 AARs from the topsrcdir.

We use the overrides to support consuming local builds. I've used it to develop new features in GV and FxR in parallel. I have used both arm and x86 overrides at the same time. I frequently have both x86 and arm builds of GV in the same directory and just switch in my .mozconfig.

(In reply to Emily Toop (:fluffyemily) from comment #4)

• Firefox Send - they're in the process of starting out with GV so they may be too early stage to be affected.

Thanks, Emily -- I added it to my list in #c3.

(In reply to Randall Barker [:rbarker] from comment #5)

(In reply to Nick Alexander :nalexander [he/him] from comment #1)

rbarker: I notice that FirefoxReality supports:

a) paths to AARs, not just to Maven repositories. Do you only use this for local GeckoView AARs, i.e., that you built?. Or do you also download AARs and plug them in? The latter is not easy to support generically.

b) separate paths to ARM and x86 AARs. Do you ever actually use both of these at the same time? This doesn't really make sense if we make substitution "topsrcdir/topobjdir" centric, since you'll never get both ARM and x86 AARs from the topsrcdir.

We use the overrides to support consuming local builds. I've used it to develop new features in GV and FxR in parallel.

Thanks for the speedy response. Yep, this is what I'm trying to make uniform across projects.

I have used both arm and x86 overrides at the same time. I frequently have both x86 and arm builds of GV in the same directory and just switch in my .mozconfig.

OK, that's great. This will work well: if you specify just a topsrcdir, it'll use the "default" topobjdir; if you update your mozconfig, that'll change. You won't get APKs with support for both x86 and ARM, but if we really need it we can grow it.

I pushed a couple PRs to downstream consumers. This might be better served in a shared Gradle plugin, even up-front. It's not really possible to handle this gracefully in all consumers with an apply from: script. I'll investigate doing this that way instead, 'cuz it might be a better overall outcome. The downside is that it doesn't "vector" through mozilla-central, which is the best place for collecting and communicating best practices.

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

mcomella: eventually this might end up in a shared Gradle plugin -- just getting it onto your radar.

Got it: I'll ping you when this is ready (hopefully today).

mcomella: fluffyemily: In the meantime, can you help me collect downstream consumers we should try to align on this approach? I'm aware of:

Besides the other sample browsers directly in the android-components repository, those are all the ones I can think of. You may wish to send an email to mobile-all to track down any other consumers though.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:nalexander, could you have a look please?

(In reply to Release mgmt bot [:sylvestre / :calixte] from comment #10)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:nalexander, could you have a look please?

We expect to handle this differently, in a plugin, like https://github.com/mozilla-mobile/android-automation-tools/pull/46.

(In reply to Nick Alexander :nalexander [he/him] from comment #11)

(In reply to Release mgmt bot [:sylvestre / :calixte] from comment #10)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:nalexander, could you have a look please?

We expect to handle this differently, in a plugin, like https://github.com/mozilla-mobile/android-automation-tools/pull/46.

And, having investigated this, the tide has turned yet again and the approach in this ticket seems best. I'm going to land a slightly updated version of this now.

sebastian: can you do the PR for a-c as part of your testing? I'm quite confident the snakeyaml issue, at least, is addressed :)

https://hg.mozilla.org/mozilla-central/rev/9417714d5e34

(In reply to Nick Alexander :nalexander [he/him] from comment #14)

sebastian: can you do the PR for a-c as part of your testing? I'm quite confident the snakeyaml issue, at least, is addressed :)

Nice! Will do.

Continuing in:
https://github.com/mozilla-mobile/android-components/issues/4068