Separate AutoValue Annotations and Processor into different dependencies.

[rharter]

It would be really helpful, especially in constrained environments like Android, to have the Annotations and the Processor separated into different dependencies. The current structure leads to unnecessarily bloated output binaries.

Currently on Android, if the user includes AutoValue using compile 'com.google.auto.value:auto-value:1.2' then all of the processing classes and all of the shaded classes are included in the final binary. There are ways around this, but they are hacky and unclear.

Separating the annotations from the processor would allow something like the following:

compile 'com.google.auto.value:auto-value-annotation:1.2'
apt `com.google.auto.value:auto-value:1.2

This naming would allow existing users to update smoothly (assuming auto-value depends on auto-value-annotation)

This would only include the minimal set of classes (annotations) required in the output binary and ensure that all other classes, including shaded classes, aren't unnecessarily included.

[JakeWharton]

Best workaround I've found so far is using apt for the dependency and just copy/pasting the AutoValue annotation type into your app. But it would be great to not have to do this.

[JakeWharton]

Also, +1 😀

[alangpierce]

AutoValue doesn't have any runtime dependencies (since the AutoValue annotation itself only has SOURCE retention), so you can use the provided scope to avoid including anything in your binary, like this:

provided 'com.google.auto.value:auto-value:1.1'
apt 'com.google.auto.value:auto-value:1.1'

[JakeWharton]

This is what everyone is doing. It's bad for two reasons:

• Obvious duplication across configurations is error prone and annoying
• It exposes the types and all dependencies on the classpath for IDE autocompletion

[tbroyer]

While I tend to agree:

• Auto Value no longer depends on Velocity, so all dependencies are now shaded
• As suggested by @jbgi, change the Maven build for AutoValue to use the org.immutables.tools... #264 would hide shaded dependencies from IDE autocompletion
• the processor itself could be similarly hidden from autocompletion if that's a problem (people using Maven would see the processor if not hidden that way, even when split into a separate JAR, as maven doesn't have first-class support for annotation processors – i.e. an "apt scope" or maven-compiler-plugin configuration).

I'd note that https://immutables.github.io went the exact opposite way in their 2.0, putting everything into a single JAR under the argument that it confused users (if you ask me, their mistake was to use a "standalone" JAR containing the processor and the annotations, in addition to an annotation-only JAR, rather than making a "processor" JAR with a dependency on the annotation-only JAR).

That said, did I say I tend to agree? Having the same dependency in two distinct Gradle configurations (provided and apt when using the com.neenbedankt.android-apt plugin, compileOnly and apt with the net.ltgt.apt plugin) feels wrong and is "error prone and annoying", as you put it.

[rharter]

For the sake of discussion on the user confusion point, I'd like to point out that this is exactly what Dagger and it seems to work well.

Correct me if I'm wrong, but with the processing jar having a dependency on the annotations jar, there wouldn't actually be any difference in the workflow for Maven users since, as you said, Maven doesn't have an apt scope.

[tbroyer]

@rharter Absolutely, wouldn't change much things, and would have a few happy consequences.

So to clarify: I'm +1 to making 2 artifacts the same way Dagger (both 1 and 2) do, i.e. with a processor (or compiler, I don't care) one depending on the annotations (or core) one; not the way Immutables 1 did (value-standalone being a superset of value). And if there's demand for a standalone JAR, do it like Dagger 1 does (com.squareup.dagger:dagger-compiler:1.2.2:jar-with-dependencies).
I don't think this is critical though, as the major downsides of the current approach should be solved in the next version (either already committed or in review).

[frankiesardo]

Previous discussion on #250 as well. @eamonnmcmanus recently reopened it.

I'm not gonna restate my argument but, yeah, separating annotation and processor would be a great thing, especially now that AutoValue is getting extensions. If AutoValueExtension were still an interface I would have included it in the annotation library as well, so that any extension only has to depend on that lightweight dependency. I like to think that the annotation library is the publicly facing api and the processor is an implementation detail, but maybe it's just me.

[tbroyer]

If AutoValueExtension were still an interface I would have included it in the annotation library as well, so that any extension only has to depend on that lightweight dependency. I like to think that the annotation library is the publicly facing api and the processor is an implementation detail, but maybe it's just me.

It's more that they go into independent "classpaths" (to me at least): annotations are needed by the code that you compile (so goes into the compile classpath), and the processor goes into processor path. Technically, the processor doesn't even need to depend on the annotation (see how https://github.com/tbroyer/bullet/blob/aff7e4d3d4a944aef2c891a81d68919fa0000c63/compiler/src/main/java/bullet/impl/ComponentProcessor.java didn't depend on Dagger).
Given that extensions are run from the processor, and never referenced from the code being compiled, AutoValueExtension has no reason to be in the annotation library. You could argue for an extension-api library but that's a different story.

[rharter]

I agree, I'd like to see the minimal code required by the compiled code in
the compile path, and everything else in the processor path.

On Sun, Sep 20, 2015, 4:03 AM Thomas Broyer notifications@github.com
wrote:

If AutoValueExtension were still an interface I would have included it in
the annotation library as well, so that any extension only has to depend
on that lightweight dependency. I like to think that the annotation
library is the publicly facing api and the processor is an implementation
detail, but maybe it's just me.

It's more that they go into independent "classpaths" (to me at least):
annotations are needed by the code that you compile (so goes into the
compile classpath), and the processor goes into processor path.
Technically, the processor doesn't even need to depend on the annotation
(see how
https://github.com/tbroyer/bullet/blob/aff7e4d3d4a944aef2c891a81d68919fa0000c63/compiler/src/main/java/bullet/impl/ComponentProcessor.java
didn't depend on Dagger).
Given that extensions are run from the processor, and never referenced
from the code being compiled, AutoValueExtension has no reason to be in
the annotation library. You could argue for an extension-api library but
that's a different story.

—
Reply to this email directly or view it on GitHub
#268 (comment).

[mttkay]

+1 on separate JARs. It's really confusing to see Guava classes appear all over the place in code completion, especially if they are dependencies to the processor. I just reviewed a PR where someone accidentally used a shaded Guava class, and this would crash at runtime because the dependency is merely part of the provided config.

[mttkay]

If anyone is interested in how to solve this:

• copy @AutoValue annotation over to your code base, preserving the package name
• remove provided (or worse, compile) dependency to auto/value
• add provided dependency on javax.annotation:jsr250-api:1.0 (this makes the @Generated annotation available to the processor, otherwise it'll crash with a NullPointerException when trying to generate the implementation class)

[JakeWharton]

And that assumes you have an apt dependency on auto/value (or some other means of putting it on the -processorpath only)? This is the approach that we are currently using 👍 Although for our case I did not need the generated annotation.