3

I develop an android library. The library depends on appcompat-v7. My consumers also depend on appcompat-v7. How do I most correctly expose my appcompat dependency from the libray when publishing to a maven repository?

What I'm doing now

  • Listing the appcompat-v7 dependency as an implementation dependency in the library
  • Using android-maven-publish to publish POM files which causes the dependency to be listed with Scope "runtime"

Yet with this setup the version preference of the library bleeds onto the consumer. Here is a screenshot from the consumer's project view where the library version is using v27.0.0 and the consumer is set up with 26.1.0:

enter image description here

v27.0.0 takes presedence over v26.1.0, causing compiler errors (because the Fragment signature has changed).

Is there any way to avoid this by configuring the library different, or should this be the result? Am I wrong in assuming that different versions of the appcompat lib should be allowed in the library and in the consuming app? Should I instead publish multiple binaries, each compiled against a different version of the support library to satisfy any given consumer setup?

Nilzor
  • 18,082
  • 22
  • 100
  • 167

1 Answers1

1

Is there any way to avoid this by configuring the library different, or should this be the result?

Unfortunately, this the expected result. The reason of this issue is that JVM doesn't allow to have more than once class with the same package and name.

Am I wrong in assuming that different versions of the appcompat lib should be allowed in the library and in the consuming app?

As I said, this is a JVM restriction.

Should I instead publish multiple binaries, each compiled against a different version of the support library to satisfy any given consumer setup?

This is the only solution that you have, even do it's very painful.

JoseF
  • 1,261
  • 13
  • 30
  • I realize you can't have multiple classes with same package and name. My idea was that the client only used their version. That can maybe be solved with ResolutionStrategy? https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html Anyway that means that the library setup is correct? – Nilzor Oct 31 '17 at 15:11
  • No, unfortunately is not possible (at least I don't know how) to tell Gradle to fill your library requirement with their version. Gradle first look for the libraries (including your) and fill the requirements of the libraries , and later found that has multiple versions of the same library and uses the latest version. – JoseF Nov 02 '17 at 15:20