How do I resolve a dependency version issue with the android plugin and ASM?


(Michael Barany) #1

The deploygate plugin has a dependency on “http-builder” which in turn as a dependency on an old version of ASM. How can I resolve this dependency? Am I able to resolve it on a per-task level (for instance the tasks don’t depend on each other)? Many thanks!

buildscript {
    repositories {
        mavenCentral()
    }
      dependencies {
        classpath 'com.android.tools.build:gradle:0.7.0'
        classpath 'com.deploygate:gradle:0.4'
    }
}

(Peter Niederwieser) #2

What exact error are you getting? Is ASM correctly listed as a dependency in the plugin’s POM?


(Michael Barany) #3

When I run the lint task from the android plugin it seems to be picking up an older version of ASM.

FAILURE: Build failed with an exception.
  * What went wrong:
Execution failed for task ':AYI:lint'.
> class com.android.tools.lint.client.api.LintDriver$SuperclassVisitor has interface org.objectweb.asm.ClassVisitor as super class

More details on the Android dev tools forum: https://groups.google.com/forum/#!topic/adt-dev/Fb0hVe-VmOE


(Peter Niederwieser) #4

Recent Gradle versions use ASM 5 in order to gain Java 8 support, and ASM has a tradition of not being backwards-compatible across major versions. That said, I’m surprised that plugins apparently aren’t isolated from this.


(Michael Barany) #5

So according to Tor on the Android Dev forum, Android Lint lists ASM 4.0 as a dependency and in the DeployGate plugin, it lists a version of “http-builder” that in turn lists ASM 3.X as a dependency.

The DeployGate tasks in it’s plugin shouldn’t be conflicting with the Android plugin as they are all separate tasks that don’t depend on each other. The lint task shouldn’t be using anything from the DeployGate plugin, so how can I force that task to exclude everything from DeployGate?


(Peter Niederwieser) #6

Class loading is per project, not per plugin or task. It may not currently be possible to use these two plugins in the same project, unless they shade their ASM dependencies (i.e. compile against and bundle renamed ASM classes). You could still use them in separate projects of the same build, though.


(Michael Barany) #7

I see, so then it’s out of my hands. I thought I was reading something in the Gradle docs about dependency resolution with transitive dependencies, but I guess this issue is different?

anyways, thanks for your help.


(Peter Niederwieser) #8

According to my understanding, if the plugins really need different ASM versions (i.e. excluding one of the ASM versions isn’t good enough), there is nothing you can currently do to enable their use in the same project.