[workaround] Retrolambda is a compilation dependency when using libraries

[Wopple]

I am using the plugin version 3.2.3. I just spent the whole day trying to figure out why I was getting java 8 class files when compiling despite being sure I setup the retrolambda plugin for each of my modules. The situation I had was:

moduleA
\--moduleB
   \--moduleC

Artifacts for B and C were put into my maven repo. I was trying to run my tests for A, and it was failing at the dex step because it was getting class files with CA FE BA BE 00 00 00 34 in the header. It was complaining about this class in particular:

https://github.com/orfjackal/retrolambda/blob/master/retrolambda/src/main/java/net/orfjackal/retrolambda/files/ClasspathVisitor.java

That was strange to me because that shouldn't be a part of the output of my compilation. Running gradle dependencies in A revealed:

A
\--B
   |--C
   \--net.orfjackal.retrolambda

And there's my problem. Somehow retrolambda was becoming a transitive dependency to my compilation! Thanks to some gradle configuration I have a working workaround:

compile('foo:bar:1.2.3') {
    exclude group: 'net.orfjackal.retrolambda'
}

Oddly, compiling B and running gradle dependencies did not have any issues.

[evant]

Interesting, that certainly should not be the case. The only way retrolambda is added as a dependency is through a custom configuration retrolambdaConfig. There might be a wrinkle in how gradle handles transitive dependencies that I'm not aware about. What version of gradle are you using so I can do further testing?

[Wopple]

I am using gradle version 2.2.1. This is in an android project where all referenced modules are android library modules. I am using version 1.0.0 of the android gradle plugin.

[evant]

If you have a chance, mind updating to the latest gradle version (2.7) and seeing if the issue is still present?

[Wopple]

I just tried gradle 2.7, and the bug still presented itself. I don't have much more time to look into it today, I can get back to it on Monday.

[Wopple]

I created a minimal setup to see if it would reproduce the bug, but it did not. That tells me that something in my project setup is triggering this bug. I will keep looking.

[Wopple]

I think I figured out how to reproduce this. It requires a very strange setup:

proj1/a/build.gradle:

dependencies {
    compile('module:b:1.0.0')
    compile project(':c')
}

proj2/b/build.gradle:

dependencies {
    compile 'module:c:1.1.0'
}

proj1/c/build.gradle:

dependencies {
    // ...
}

The bug only happens if A's dependency on C is a project dependency. If I change the dependency to an artifact dependency, the bug does not happen. It only seems to happen if:

• A depends on B as an artifact
• B depends on C as an artifact
• A depends on C as a project dependency

I can fix this without the exclude group workaround by removing A's dependency on C since A will get C anyway transitively through B, or change it to an artifact dependency.

[evant]

Ok this is very weird and smells like a gradle bug. Mind creating a sample project that reproduces it? Also instead of depending on retrolambda, try just creating a custom configuration in each of the projects. ex:

configurations {
  myConfig
}

dependencies {
  myConfig 'some-random-artifact'
}

[Wopple]

Since github doesn't support attaching .zip files (wat), here's a repo that demonstrates the bug: https://github.com/Wopple/retrolambda-bug

Dependency graph: moda > modb (artifact) moda > modc (project) modb > modc (artifact)

To reproduce:

~/dir/proj1/modc$ gradle assemble publishReleasePublicationToMavenLocal ~/dir/proj2/modb$ gradle assemble publishReleasePublicationToMavenLocal ~/dir/proj1/moda$ gradle dependencies

You might need to temporarily comment out moda in settings.gradle in proj1 for the first command to run.

Below is sample output from running gradle dependencies in each of the three modules to demonstrate the bug. You can see the issue from module moda. I have also included the .pom files generated from modc and modb.

~/retrolambdabug/proj1/modc% gradle dependencies
:modc:dependencies

------------------------------------------------------------
Project :modc
------------------------------------------------------------

archives - Configuration for archive artifacts.
No dependencies

compile - Compile classpath for source set 'main'.
No dependencies

default - Configuration for default artifacts.
No dependencies

retrolambdaConfig
\--- net.orfjackal.retrolambda:retrolambda:2.0.5

runtime - Runtime classpath for source set 'main'.
No dependencies

testCompile - Compile classpath for source set 'test'.
No dependencies

testRuntime - Runtime classpath for source set 'test'.
No dependencies

BUILD SUCCESSFUL

Total time: 3.452 secs

~/retrolambdabug/proj2/modb% gradle dependencies
:modb:dependencies

------------------------------------------------------------
Project :modb
------------------------------------------------------------

archives - Configuration for archive artifacts.
No dependencies

compile - Compile classpath for source set 'main'.
\--- org.daniel:modc:1.0

default - Configuration for default artifacts.
\--- org.daniel:modc:1.0

retrolambdaConfig
\--- net.orfjackal.retrolambda:retrolambda:2.0.5

runtime - Runtime classpath for source set 'main'.
\--- org.daniel:modc:1.0

testCompile - Compile classpath for source set 'test'.
\--- org.daniel:modc:1.0

testRuntime - Runtime classpath for source set 'test'.
\--- org.daniel:modc:1.0

BUILD SUCCESSFUL

Total time: 3.559 secs

~/retrolambdabug/proj1/moda% gradle dependencies
:moda:dependencies

------------------------------------------------------------
Project :moda
------------------------------------------------------------

archives - Configuration for archive artifacts.
No dependencies

compile - Compile classpath for source set 'main'.
+--- org.daniel:modb:1.0
|    \--- org.daniel:modc:1.0 -> project :modc
|         \--- net.orfjackal.retrolambda:retrolambda:2.0.5
\--- project :modc (*)

default - Configuration for default artifacts.
+--- org.daniel:modb:1.0
|    \--- org.daniel:modc:1.0 -> project :modc
|         \--- net.orfjackal.retrolambda:retrolambda:2.0.5
\--- project :modc (*)

retrolambdaConfig
\--- net.orfjackal.retrolambda:retrolambda:2.0.5

runtime - Runtime classpath for source set 'main'.
+--- org.daniel:modb:1.0
|    \--- org.daniel:modc:1.0 -> project :modc
|         \--- net.orfjackal.retrolambda:retrolambda:2.0.5
\--- project :modc (*)

testCompile - Compile classpath for source set 'test'.
+--- org.daniel:modb:1.0
|    \--- org.daniel:modc:1.0 -> project :modc
|         \--- net.orfjackal.retrolambda:retrolambda:2.0.5
\--- project :modc (*)

testRuntime - Runtime classpath for source set 'test'.
+--- org.daniel:modb:1.0
|    \--- org.daniel:modc:1.0 -> project :modc
|         \--- net.orfjackal.retrolambda:retrolambda:2.0.5
\--- project :modc (*)

(*) - dependencies omitted (listed previously)

BUILD SUCCESSFUL

Total time: 3.41 secs

modc.pom:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.daniel</groupId>
  <artifactId>modc</artifactId>
  <version>1.0</version>
  <dependencies/>
</project>

modb.pom

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.daniel</groupId>
  <artifactId>modb</artifactId>
  <version>1.0</version>
  <dependencies>
    <dependency>
      <groupId>org.daniel</groupId>
      <artifactId>modc</artifactId>
      <version>1.0</version>
    </dependency>
  </dependencies>
</project>

[dan-dr]

I think i'm having a variation of this issue, but the workaround isn't working for me. I have an Android project consisting of 1 application project (A), 1 android library project (B), and 1 java library (C). the dependencies are basically A -> B+C B-> C C is standalone

I'm getting errors on the transformClassesWithDexForDebug task if I don't apply the retrolambda plugin on the java library project (C). While i intend to use it there anyhow, it smells like something is wrong.