"Shade" the processors to internalize their dependencies to avoid interactions with other processors that use related libraries. about auto HOT 8 OPEN

#160 for auto-value

can we do similar for auto-factory?

from auto.

Was this ever completed?

from auto.

Not for AutoFactory.

Its debatable if we should keep this issue open though - no one has complained, and repackaging isn't always "free".

from auto.

Its debatable if we should keep this issue open though - no one has complained, and repackaging isn't always "free".

The doc for auto-common says you should repackage it: https://github.com/google/auto/tree/master/common#processor-resilience

It's not done in either auto-factory nor auto-service. If it's finally OK to have auto-common as a transitive, non-repackaged, dependency, then could you update the documentation?

from auto.

Any news on this? I'm wondering what I should do in my annotation processors, wrt auto-common: have it as a dependency or not?

Currently, we have auto-common saying it should be repackaged, with auto-value and dagger following that advice; and conversely auto-factory, auto-service, compile-testing (uses MoreTypes.equivalence()), error-prone (uses MoreElements.asType, once, could probably be replaced by a simple cast), butterknife, androidx (room et al.), etc. that depend on auto-common without repackaging it.

Given the number of projects, including Google-backed ones, using auto-common as a dependency rather than repackaging it; I'd say maybe it's here to stay (i.e. you probably cannot remove the deprecated ProcessingStep or break any other API without breaking people) and:

1. the doc should be updated to reflect that; replacing the "processor resilience" section with one that guarantees forward compatibility
2. possibly revert the shading in auto-value and dagger

from auto.

I think processors should either bundle all of their own dependencies, in which case those should be shaded, or none of them, relying on them transitively. The second choice is a little dangerous, especially with Maven, because a processor can easily end up with an earlier version of a dependency on the processorpath than the one it needs.

from auto.

Maven has the exact same problem for the classpath (project dependencies), and there are workarounds (explicitly declare the dependency as a direct dependency; for project dependencies you could also use dependencyManagement, but not for annotationProcessorPaths).

I don't think anybody ever said that every single library on the (runtime) classpath should bundle and shade its own implementation dependencies (those not exposed through its APIs), so there's no reason to do it for annotation processors (or Gradle plugins, or similar constructs); and that works because there are some compatibility guarantees.

So, would you agree to commit to forward compatibility guarantees for Auto Common and update the "processor resilience" section of the doc?

from auto.

I don't see much cost in shading everything that's necessary. Binary size of processors isn't much of an issue, nor should this make a substantial difference.

FWIW we had discussions about copying AutoCommon to a new package name, improving some of rough edges of the API, and making a 1.0. We had agreement on it but haven't acted on it yet. That seems like the best way to move forward with API guarantees.

from auto.