Open Bug 1523544 Opened 11 months ago Updated 16 days ago

Rename com.google.android.exoplayer2 in mobile/android to not conflict with consumer's exoplayer2 version

Categories

(GeckoView :: General, defect, P3)

Unspecified
Android
defect

Tracking

(firefox67 affected)

Tracking Status
firefox67 --- affected

People

(Reporter: hafizmohd013, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

1)compile error from org.mozilla.geckoview:geckoview-${geckoviewChannel}-x86_64:${geckoviewVersion}
2)error: cannot find symbol class Factory and incompatible types: SimpleExoPlayer cannot be converted to Player as well as error: incompatible types: <anonymous com.google.android.exoplayer2.Player.EventListener> cannot be converted to com.google.android.exoplayer2.ExoPlayer.EventListener

Actual results:

I already own use exoplayer2 using my library and seem that it is conflict with class jar under org.mozilla.geckoview:geckoview-${geckoviewChannel}-x86_64:${geckoviewVersion} which is contain library exoplayer2 also. The question is that how to exclude this library from interrupt with my current library.

Expected results:

Your library exoplayer2 should not interrupt with my exoplayer2. Please do some thing

Component: Android Sync → General
Product: Firefox for Android → GeckoView
Summary: com.google.android.exoplayer2 → build conflict with com.google.android.exoplayer2

Your library exoplayer2 should not interrupt with my exoplayer2. Please do some thing

This isn't how Android (really, Java) works. It's just not true that if you use library X then you can use part of library X's namespace without consequences.

The version of exoplayer2 that GeckoView is using is both old and has been modified, so it's really not possible to share a copy of that code with consumers. That means we can either:

  1. rename the package space for GeckoView's exoplayer2;
  2. make you, the consumer, rename the package space for your exoplayer2.

I think 1) makes GV a better ecosystem participant. This should be the long-term goal: it looks like a big find-and-replace, followed by some manual testing.

I think 2) is possible right now: look into "shadow JARs"; I've been impressed with https://imperceptiblethoughts.com/shadow/ (although I haven't used it). That is, mangle your namespace such that you avoid this problem, 'cuz GV isn't going to do this quickly. (But I'd review a patch, if one was put forward!)

N.b.: if GV ever stops vendoring exoplayer2 into the tree and starts consuming exoplayer2 from a Maven publication, we should start shadow-relocating our version of exoplayer2 (or accept that consumers will change the version out from underneath us, which isn't really a bad thing).

Thanks for the bug report -- this is a thing that the GV team haven't really needed to think of yet!

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: build conflict with com.google.android.exoplayer2 → Rename com.google.android.exoplayer2 in mobile/android to not conflict with consumer's exoplayer2 version
OS: Unspecified → Android
Priority: -- → P3

Nils, do we know how many people are still even hitting the HLS path in Gecko these days? I'm wondering if we could just nuke this.

Flags: needinfo?(drno)
You need to log in before you can comment on or make changes to this bug.