Separate AutoValue Annotations and Processor into different dependencies. #268

Open
rharter opened this Issue Sep 10, 2015 · 26 comments

Projects

None yet
@rharter
Contributor
rharter commented Sep 10, 2015

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
Contributor

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
Contributor

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
Contributor

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
Contributor
tbroyer commented Sep 10, 2015

While I tend to agree:

  • Auto Value no longer depends on Velocity, so all dependencies are now shaded
  • #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
Contributor
rharter commented Sep 10, 2015

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
Contributor
tbroyer commented Sep 10, 2015

@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).

@tbroyer tbroyer referenced this issue in codejuicer/asynchronize Sep 14, 2015
Open

Split annotations and processor in different projects #2

@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
Contributor
tbroyer commented Sep 20, 2015

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
Contributor
rharter commented Sep 20, 2015

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
mttkay commented Sep 25, 2015

+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
mttkay commented Sep 25, 2015

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
Contributor

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
mttkay commented Sep 25, 2015

Yes that assumes the apt dependency is still in place.

On Fri, Sep 25, 2015, 16:51 Jake Wharton notifications@github.com 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
mttkay commented Oct 1, 2015

@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
Contributor

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 notifications@github.com
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
mttkay commented Oct 1, 2015

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 notifications@github.com
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 notifications@github.com
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
Contributor
cgruber commented Oct 10, 2015

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 notifications@github.com
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
Contributor

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.

@hzsweers

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

@CoatedMoose CoatedMoose added a commit to CoatedMoose/auto that referenced this issue Jun 27, 2016
@CoatedMoose CoatedMoose Separate auto-factory compiler and annotations.
No code changes, just moving files and pom configuration changes.

See issue google/auto#268.
acf61ec
@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.

@hzsweers
hzsweers commented Sep 12, 2016 edited

Can probably close this in favor of #374 now?

@CoatedMoose

I would say it makes sense to move it to the home in the new project. It wouldn't really be an "in favour of" kind of thing, since separating projects doesn't address separating the compiler and the interface. I assume this issue should be opened against all 3 projects now.

@cgruber
Contributor
cgruber commented Sep 12, 2016

Yes - this is a separate concern from splitting hte projects themselves
into different github homes. As part of the bug-scrub I'll need to do
migrating projects, I'll replicate the substance of this issue in each of
the projects.

On Sun, 11 Sep 2016 at 21:37 Andrew Crichton notifications@github.com
wrote:

I would say it makes sense to move it to the home in the new project. It
wouldn't really be an "in favour of" kind of thing, since separating
projects doesn't address separating the compiler and the interface. I
assume this issue should be opened against all 3 projects now.

β€”
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#268 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUN4gNBa9R4auix6jHQE3_CsWno-bKPks5qpNb9gaJpZM4F6ul7
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment