Shade dependencies

[Zubnix]

Currently dagger compiler has a (compile time) dependency on guava. Ideally this should be shaded as not to conflict with any other runtime provided guava dependency by the user.

Use case:
User forgets to add it's own guava dependency -> project finds dagger compiler guava version -> user uses wrong guava version

[tbroyer]

Ideally, dagger-compiler would not be on the classpath but on the processorpath, so the Guava dependency would be isolated, and a missing Guava dependency on the classpath would cause compilation failures.

Indeed Maven is among the few build tools that don't allow you to set the processorpath¹, and will include dagger-compiler and its dependencies (assuming you've configured it as optional or provided) even in the test classpath, so you won't even be able to detect the issue when running tests (only way would be to have tests in a separate Maven module; yay Maven!)

¹ see https://issues.apache.org/jira/browse/MCOMPILER-203, https://issues.apache.org/jira/browse/MCOMPILER-134, and https://issues.apache.org/jira/browse/MCOMPILER-75 (and yes, you read that right, this is an open issue for 7 years or so)

[netdpb]

I don't think we should contort Dagger to work around a known bug in Maven that only affects some users.

[cpovirk]

Does this end up affecting everyone who wants to compile with a newer version of Guava than Dagger is using (and use APIs from that newer version)? I'm changing Caliper to depend on Guava 19.0, but the compile fails because it's using the dagger-compiler (18.0?) copies of Guava classes.

Oddly, this seems to be the case even for Dagger 2.1-SNAPSHOT, which I would expect to include Guava 19.0-rc2. I'm wondering if the old Guava sneaks in through one of the compiler's other deps. To prevent this, I tried spraying pom.xml and compiler/pom.xml with exclusions, but this doesn't seem to have helped.

(Google Dagger people may also recall a conflict with another annotation processor (http://go/nbver). That won't normally happen in the Google depot, but presumably it can happen externally.)

[tbroyer]

@cpovirk Yes, this is the problem. For some reason dagger-compiler includes Guava classes non-relocated, instead of having a compile-time dependency on it (as originally reported here).
BTW it also includes google-java-format, Eclipse JDT and jsr305; I think this is the reason Guava ends up in the JAR: it's in the google-java-format JAR along with those other "dependencies".

[cpovirk]

@tbroyer Ah, it never occurred to me that one of the jar would contain it directly. Thanks!

I've filed google/google-java-format#20

[tbroyer]

Just a note that MCOMPILER-203 has been fixed in maven-compiler-plugin:3.5 so you can now have a proper -processorpath separate from your -classpath (and the Guava version used by Dagger can no longer conflict or interfere in any way with your own Guava dependency, or lack thereof); see #293