1

I've got a raw project using 

compile "com.library1:library1:2.0.4" compile "com.library2:library2:3.0.0"

whereas both library1:2.0.4 and library2:3.0.0 share the same namespace (have the same package names). Is there a clean way to let them coexist within one project without build time errors like:

Execution failed for task ':app:transformClassesWithDexForDebug'. > com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.dex.DexException: Multiple dex files define (...)/BuildConfig;
Improve this question
7
  • Why are you trying to use different versions of the same library? Commented Sep 4, 2017 at 14:50
  • yes, but the migration has to be done over a longer period of time Commented Sep 4, 2017 at 14:53
  • Then deprecate the methods in the new versions and remove the old dependency Commented Sep 4, 2017 at 14:55
  • As written above I need to keep both libraries referred over a period of time. My code must compile and use both of them. Commented Sep 4, 2017 at 15:02
  • I'm not trying to disagree, just don't understand. According to semantic versioning, 2.3.0 isn't a major breaking change from 2.0.4 Commented Sep 4, 2017 at 15:08

1 Answer 1

Reset to default
1

What you need is Gradle Shadow plugin. I haven't used it, so I cannot give you more specific advice than pointing you to the docs, but I think that's the way to go, as some colleagues have told me that they've successfully used it for similar cases.

Notice that this process renames one of the libraries package name, and you will end up with something similar to:

  • library1 -> com.library1
  • library2 -> com.newlibrary1 (instead of com.library1 too)

So, if you rename the second library, at the end of the process (after removing old library) you will either have to disable the renaming of the second library and do a "Find in files" to change all the references to the renamed package; or leave the rename enabled forever. For me, first option will be the best.

See also this question Repackaging .jar-s in Android .aar library, though I'm not sure if it's already outdated.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

You can also exclude the group / artifact id from the dependencies
@cricket_007 Yes, in other scenarios that would be a solution, but I understand that he's willing to migrate from one version to another gradually.
Just like the Android SDK, why not mark things as deprecated?
looks like a solution, will give it a try and drop here my feedback
it fixes the issue
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.