Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Maven unable to resolve 2.12.x exoplayer-core dependencies #8353

Closed
space-pope opened this issue Dec 15, 2020 · 6 comments
Closed

Maven unable to resolve 2.12.x exoplayer-core dependencies #8353

space-pope opened this issue Dec 15, 2020 · 6 comments
Assignees
@andrewlewis
Labels
bug

Comments

@space-pope
Copy link

space-pope commented Dec 15, 2020 •
edited

Gradle seems to have no problem downloading ExoPlayer, but I maintain a Java library that uses Maven for dependency management, and the following dependency:

      <dependency>
         <groupId>com.google.android.exoplayer</groupId>
         <artifactId>exoplayer-core</artifactId>
         <version>2.12.2</version>
         <type>aar</type>
         <scope>provided</scope>
      </dependency>

produced the following error during mvn compile (or any other task that pulls dependencies):

The following artifacts could not be resolved: com.google.android.exoplayer:exoplayer-common:jar:2.12.2, com.google.android.exoplayer:exoplayer-extractor:jar:2.12.2

I could see via bintray's web interface that the files are there, so I dug further. This appears to be related to the pom files generated by Gradle. I can fix the problem by:

  1. Editing the exoplayer-core pom file downloaded by Maven, adding the <type>aar</type> line to its exoplayer-common and exoplayer-extractor dependencies
  2. Removing exoplayer-common and exoplayer-extractor directories from my local repository (so Maven doesn't think they're cached)
  3. Rerunning the Maven task
  4. Editing the newly downloaded exoplayer-extractor pom file, again adding <type>aar</type> to its exoplayer-common dependency
  5. Running the Maven task one last time

I would expect having <packaging>aar</packaging> under the project element (as ExoPlayer poms do) to address this problem, but apparently not, at least for runtime-scoped dependencies.

Note that I didn't have this problem with 2.11.x—exoplayer-core doesn't have runtime dependencies on the other libraries in that version.
@tonihei
Copy link
Collaborator

tonihei commented Dec 17, 2020

We added an internal dependency in 2.12.0 from core to common and extractor. In Gradle this should be resolved automatically as you noted. I'm not sure who's creating the pom files you are using here and whether it's expected that they contain dependency information. @ojw28 might know more about this.

@ojw28 ojw28 assigned andrewlewis and unassigned ojw28 Dec 17, 2020
@ojw28
Copy link
Contributor

ojw28 commented Dec 17, 2020

I guess this is the same issue as @andrewlewis on the bintray-release project in novoda/bintray-release#212. We might just solve it by migrating away from bintray-release, which we need to do anyway for other reasons.

kim-vde pushed a commit that referenced this issue Feb 19, 2021
@andrewlewis @kim-vde
Add Maven publishing support
7b119be 
The release AAR and Android sources are included for each published artifact.

Issue: #5246
Issue: #8353

#minor-release

PiperOrigin-RevId: 358146555
marcbaechinger pushed a commit that referenced this issue Feb 25, 2021
@andrewlewis @marcbaechinger
Add Maven publishing support
e3adac5 
The release AAR and Android sources are included for each published artifact.

Issue: #5246
Issue: #8353

#minor-release

PiperOrigin-RevId: 358146555
@andrewlewis
Copy link
Collaborator

I had thought that our migration to maven-publish would fix this but actually it appears <type>aar</type> is still missing from the dependency declarations. There is a workaround mentioned in gradle/gradle#3170 (comment).

@space-pope
Copy link
Author

space-pope commented Jul 12, 2021 •
edited

Is there any update to share on this? I'm still unable to locate exoplayer-common via maven as of version 2.14.1.

@andrewlewis
Copy link
Collaborator

There aren't any updates I'm afraid.

tonihei added a commit that referenced this issue Jan 4, 2022
@tonihei
Add workaround for missing <type>aar</type> tags in POM
4c343ba 
There is an open Gradle bug that dependencies with AARs are not marked
as such in the created POM files (gradle/gradle#3170).

This causes issues building ExoPlayer with Maven POMs only.
(Issue: #8353).

This change adds the workaround suggested on the Gradle bug until
the bug is fixed. As we have a mixture of JAR and AAR dependencies,
we need to maintain a lookup table to know which dependencies have AARs.
The current code throws when a new dependency is added and it's not
classified.

#minor-release

PiperOrigin-RevId: 417797407
@tonihei
Copy link
Collaborator

tonihei commented Jan 4, 2022

The commit above will work around the issue in future releases.

@tonihei tonihei closed this as completed Jan 4, 2022
tonihei added a commit to androidx/media that referenced this issue Jan 5, 2022
@tonihei
Add workaround for missing <type>aar</type> tags in POM
bf2c652 
There is an open Gradle bug that dependencies with AARs are not marked
as such in the created POM files (gradle/gradle#3170).

This causes issues building ExoPlayer with Maven POMs only.
(Issue: google/ExoPlayer#8353).

This change adds the workaround suggested on the Gradle bug until
the bug is fixed. As we have a mixture of JAR and AAR dependencies,
we need to maintain a lookup table to know which dependencies have AARs.
The current code throws when a new dependency is added and it's not
classified.

#minor-release

PiperOrigin-RevId: 417797407
@google google locked and limited conversation to collaborators Mar 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@andrewlewis andrewlewis

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@andrewlewis @space-pope @ojw28 @tonihei