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 [email protected]
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.

[mttkay]

Yes that assumes the apt dependency is still in place.

On Fri, Sep 25, 2015, 16:51 Jake Wharton [email protected] wrote:

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

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

[mttkay]

@JakeWharton about the NullPointerException when @Generated is missing. It only occurs in Android projects, and there was an issue for it actually: #240

It might be due to differences in how the apt config works in either project flavor.

[JakeWharton]

Got it. I'm using a deployed version of Ryan's extensions PR based on
master which is why I don't see it or need to include it.

On Thu, Oct 1, 2015 at 5:28 AM Matthias Käppler [email protected]
wrote:

@JakeWharton https://github.com/JakeWharton about the
NullPointerException when @generated is missing. It only occurs in
Android projects, and there was an issue for it actually: #240
#240

It might be due to differences in how the apt config works in either
project flavor.

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

[mttkay]

Ah, makes sense. Good to hear this will be resolved in 1.2 then.

On Thu, Oct 1, 2015 at 4:36 PM Jake Wharton [email protected]
wrote:

Got it. I'm using a deployed version of Ryan's extensions PR based on
master which is why I don't see it or need to include it.

On Thu, Oct 1, 2015 at 5:28 AM Matthias Käppler [email protected]
wrote:

@JakeWharton https://github.com/JakeWharton about the
NullPointerException when @generated is missing. It only occurs in
Android projects, and there was an issue for it actually: #240
#240

It might be due to differences in how the apt config works in either
project flavor.

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

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

[CoatedMoose]

I am interested in this as well. I would also like to see a similar change made to auto-factory.

[cgruber]

We're a little behind while I am working on our open-source tooling, but I
see no particular reason to not do this. Unless Eamonn and/or Kevin have
objections, I'm fine with separating these.

On Thu, 8 Oct 2015 at 12:56 Andrew Crichton [email protected]
wrote:

I am interested in this as well. I would also like to see a similar change
made to auto-factory.

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

[artem-zinnatullin]

Any updates on this? Will be great to have separate jars in 1.2-rc2!

[eamonnmcmanus]

We might or might not split the artifacts for 1.2, but the urgency of doing so is much less since all dependencies have been shaded with a $ before the class name.

[ZacSweers]

We're on to 1.3 coming up, would be great to see this given more consideration.

[CoatedMoose]

I opened a pull request (#352) to do this for auto-factory. I intend to do it for auto-value as well (time permitting I will do it for auto-service), but want to make sure what I have done is desired way. I have done it by making the factory module have 2 sub-modules (core and compiler). I could see wanting to do it by splitting the module directly at the root, but given that the project root isn't meant to be built "normally", I figured this method would be preferable.

[simtel12]

The linter in the Android Gradle 3.0-alpha3 plugin now gives an InvalidPackage error because javax is not included in Android. This is with the following configuration:

    annotationProcessor "com.google.auto.value:auto-value:$AUTO_VALUE_VERSION"
    compileOnly "com.google.auto.value:auto-value:$AUTO_VALUE_VERSION"

I assume that if there were another annotation-only artifact for the compileOnly side then lint wouldn't see the javax usage.

[VeeraAnudeep]

@simtel12 Figured out any way to sort it out?

[simtel12]

@VeeraAnudeep Honestly, I'm not sure. I updated to 3.0-alpha4, a bunch of other stuff changed in our source, and I'm no longer getting the lint error. I may have worked around it, or it may have been fixed in alpha4. :\

My suggestion, try updating to alpha4.

[JakeWharton]

The lack of a separate artifact is now breaking users of Dagger. The Dagger compiler sees the transitive Guava dependency and generates code assuming it will be available at runtime.

[tbroyer]

@JakeWharton Guava is not a transitive dependency, it's shaded into auto-value (into autovalue/shaded/com/google$/common/) so no, it does not break users of Dagger (until proven otherwise).

[JakeWharton]

Damn. I'm just trying to push this issue through 😞 . It's annoying to have to maintain a separate annotations artifact.

[tbroyer]

I've stopped worrying and just use

compileOnly 'com.google.auto.value:auto-value:1.5.1'
annotationProcessor 'com.google.auto.value:auto-value:1.5.1'

Dependencies are properly shaded, and "hidden" by prefixing the class names with a $, at least since 1.2, 1½ years ago: #268 (comment)

[tmtron]

Here are my 2 cents for splitting up the jar:

It will improve performance and keep the classpath clean.

Quote from Use the annotation processor dependency configuration:

In previous versions of the Android plugin for Gradle, dependencies on the compile classpath were automatically added to the processor classpath. That is, you could add an annotation processor to the compile classpath and it would work as expected. However, this causes a significant impact to performance by adding a large number of unnecessary dependencies to the processor.

Another disadvantage of the single-jar approach is that Android users must usually disable an error check
and setup proguard-dontwarn -rules to exclude the processor dependencies.

[bejibx]

Another quote from Android Gradle Plugin 3.0.0 migration guide:

If the plugin detects annotation processors on the compile classpath, your build fails and you get an error message that lists each annotation processor on the compile classpath.
...
you can restore behavior to that of Android plugin 2.3.0 by setting includeCompileClasspath true. However, restoring behavior to version 2.3.0 is not recommended, and the option to do so will be removed in a future update.

So android-gradle-plugin 3.0.0 users are forced to set includeCompileClasspath option until next plugin release or to use standalone annotations artifact by Jake Wharton to build projects.

[tasomaniac]

Also because of this Dagger version 2.12 thinks that guava is available and uses ImmutableSet from guava. Which basically breaks compilation.
Also because of this Android tools 3.x version warning, we went ahead and used Jake Wharton s small lib. Everything works fine.

[bejibx]

Also because of this Dagger version 2.12 thinks that guava is available and uses ImmutableSet from guava. Which basically breaks compilation.

This is probably not true. I had same problem and found out it was actually auto-value-gson who adds Guava to classpath and not AutoValue. See conversation above - #268 (comment).

[tasomaniac]

This is definitely possible. We did have gson library and did the same change together. I assumed it is a problem in both libraries. Gson one does provide separate annotation artifact though.

[ronshapiro]

Was just discussing this with @eamonnmcmanus - we're thinking that creating com.google.auto.value:auto-value-annotations:ver would be the best way to not break anyone that currently depends on com.google.auto.value:auto-value and upgrades to the new version (as opposed to to keeping auto-value just the annotations and adding auto-value-processor). Does that make sense?

[ronshapiro]

@JakeWharton mentioned offline that the above comment makes sense to him. I'm going to try and get this taken care of.

[Madhuri98]

compileOnly 'com.google.auto.value:auto-value:1.5.2'
annotationProcessor 'com.google.auto.value:auto-value:1.5.2'

[cpovirk]

Reopening in light of #352 (comment)

[cpovirk]

No, wait, sorry, this one is about AutoValue... :)