New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate AutoValue Annotations and Processor into different dependencies. #268

Closed
rharter opened this Issue Sep 10, 2015 · 42 comments

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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Sep 10, 2015

Member

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.

Member

JakeWharton commented Sep 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Sep 10, 2015

Member

Also, +1 😀

Member

JakeWharton commented Sep 10, 2015

Also, +1 😀

@alangpierce

This comment has been minimized.

Show comment
Hide comment
@alangpierce

alangpierce Sep 10, 2015

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'

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 comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Sep 10, 2015

Member

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
Member

JakeWharton commented Sep 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Sep 10, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@rharter

rharter Sep 10, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Sep 10, 2015

Contributor

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

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

@frankiesardo

This comment has been minimized.

Show comment
Hide comment
@frankiesardo

frankiesardo Sep 15, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Sep 20, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@rharter

rharter Sep 20, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@mttkay

mttkay 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 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

This comment has been minimized.

Show comment
Hide comment
@mttkay

mttkay 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)

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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Sep 25, 2015

Member

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.

Member

JakeWharton commented Sep 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mttkay

mttkay 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 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

This comment has been minimized.

Show comment
Hide comment
@mttkay

mttkay 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.

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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Oct 1, 2015

Member

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

Member

JakeWharton commented Oct 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mttkay

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

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

This comment has been minimized.

Show comment
Hide comment
@CoatedMoose

CoatedMoose Oct 8, 2015

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

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

@cgruber

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Oct 10, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@artem-zinnatullin

artem-zinnatullin Mar 22, 2016

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

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

@eamonnmcmanus

This comment has been minimized.

Show comment
Hide comment
@eamonnmcmanus

eamonnmcmanus Mar 22, 2016

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.

Contributor

eamonnmcmanus commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hzsweers

hzsweers Jun 24, 2016

Contributor

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

Contributor

hzsweers commented Jun 24, 2016

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

CoatedMoose added a commit to CoatedMoose/auto that referenced this issue Jun 27, 2016

Separate auto-factory compiler and annotations.
No code changes, just moving files and pom configuration changes.

See issue google/auto#268.
@CoatedMoose

This comment has been minimized.

Show comment
Hide comment
@CoatedMoose

CoatedMoose Jun 27, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@hzsweers

hzsweers Sep 12, 2016

Contributor

Can probably close this in favor of #374 now?

Contributor

hzsweers commented Sep 12, 2016

Can probably close this in favor of #374 now?

@CoatedMoose

This comment has been minimized.

Show comment
Hide comment
@CoatedMoose

CoatedMoose Sep 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@cgruber

cgruber Sep 12, 2016

Contributor

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
.

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
.

@bubenheimer

This comment has been minimized.

Show comment
Hide comment
@bubenheimer

bubenheimer Apr 3, 2017

Just FYI: Android Studio Preview 4 now throws an error when using the common

provided 'com.google.auto.value:auto-value:1.4'
annotationProcessor 'com.google.auto.value:auto-value:1.4'

Error:Execution failed for task ':app:javaPreCompileDevCheckDebugUnitTest'.
> Annotation processors must be explicitly declared now.  The following dependencies on the compile classpath are found to contain annotation processor.  Please add them to the annotationProcessor configuration.
    - auto-value-1.4.jar
  Alternatively, set android.defaultConfig.javaCompileOptions.annotationProcessorOptions.includeCompileClasspath = true to continue with previous behavior.  Note that this option is deprecated and will be removed in the future.
  See https://developer.android.com/r/tools/annotation-processor-error-message.html for more details.`

The approach from #268 (comment) is still good.

I would not be surprised if the behavior changed again to allow provided dependencies that include annotation processors. Based on the error message and suggested (broken) build option workaround, the primary focus was compile dependencies, with less consideration given to provided dependencies.

N.B. the link in the error message is not active for me yet, so I don't know what explanation it will offer eventually.

Just FYI: Android Studio Preview 4 now throws an error when using the common

provided 'com.google.auto.value:auto-value:1.4'
annotationProcessor 'com.google.auto.value:auto-value:1.4'

Error:Execution failed for task ':app:javaPreCompileDevCheckDebugUnitTest'.
> Annotation processors must be explicitly declared now.  The following dependencies on the compile classpath are found to contain annotation processor.  Please add them to the annotationProcessor configuration.
    - auto-value-1.4.jar
  Alternatively, set android.defaultConfig.javaCompileOptions.annotationProcessorOptions.includeCompileClasspath = true to continue with previous behavior.  Note that this option is deprecated and will be removed in the future.
  See https://developer.android.com/r/tools/annotation-processor-error-message.html for more details.`

The approach from #268 (comment) is still good.

I would not be surprised if the behavior changed again to allow provided dependencies that include annotation processors. Based on the error message and suggested (broken) build option workaround, the primary focus was compile dependencies, with less consideration given to provided dependencies.

N.B. the link in the error message is not active for me yet, so I don't know what explanation it will offer eventually.

@jimandreas

This comment has been minimized.

Show comment
Hide comment
@jimandreas

jimandreas May 9, 2017

The link in the error message works now, and takes you here. One temporary workaround listed is pretty simple as shown below. I tried it on the android-boilerplate repo at AS2.4P7 and it suppressed the compile error.

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                includeCompileClasspath false
            }
       }
    }
}

The link in the error message works now, and takes you here. One temporary workaround listed is pretty simple as shown below. I tried it on the android-boilerplate repo at AS2.4P7 and it suppressed the compile error.

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                includeCompileClasspath false
            }
       }
    }
}
@simtel12

This comment has been minimized.

Show comment
Hide comment
@simtel12

simtel12 Jun 9, 2017

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.

simtel12 commented Jun 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@VeeraAnudeep

VeeraAnudeep Jun 23, 2017

@simtel12 Figured out any way to sort it out?

@simtel12 Figured out any way to sort it out?

@simtel12

This comment has been minimized.

Show comment
Hide comment
@simtel12

simtel12 Jun 23, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Oct 11, 2017

Member

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.

Member

JakeWharton commented Oct 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Oct 11, 2017

Contributor

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

Contributor

tbroyer commented Oct 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Oct 11, 2017

Member

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

Member

JakeWharton commented Oct 11, 2017

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

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Oct 11, 2017

Contributor

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)

Contributor

tbroyer commented Oct 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tmtron

tmtron Oct 13, 2017

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.

tmtron commented Oct 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bejibx

bejibx Nov 2, 2017

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.

bejibx commented Nov 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tasomaniac

tasomaniac Nov 2, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@bejibx

bejibx Nov 2, 2017

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

bejibx commented Nov 2, 2017

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 comment has been minimized.

Show comment
Hide comment
@tasomaniac

tasomaniac Nov 2, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@ronshapiro

ronshapiro Feb 28, 2018

Contributor

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?

Contributor

ronshapiro commented Feb 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ronshapiro

ronshapiro Mar 2, 2018

Contributor

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

Contributor

ronshapiro commented Mar 2, 2018

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

@ronshapiro ronshapiro referenced this issue Mar 12, 2018

Merged

Moe Sync #606

ronshapiro added a commit that referenced this issue Mar 12, 2018

Create an auto-value-annotations artifact separate from the processor
Fixes #268

I followed the instructions in https://maven.apache.org/guides/mini/guide-using-one-source-directory.html because it seemed like the easiest way forward without moving around any files.

RELNOTES=`@autovalue`, `@AutoAnnotation`, `@AutoOneOf`, and `@memoized` are now in a separate artifact, `auto-value-annotations`. This allows users to specify the annotations in compile scope and the processor in an annotation processing scope, without leaking the processor to a release binary. To upgrade to this version of auto-value, you'll need to add this new artifact as a dependency.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188505001

@ronshapiro ronshapiro closed this in #606 Mar 12, 2018

ronshapiro added a commit that referenced this issue Mar 12, 2018

Create an auto-value-annotations artifact separate from the processor
Fixes #268

I followed the instructions in https://maven.apache.org/guides/mini/guide-using-one-source-directory.html because it seemed like the easiest way forward without moving around any files.

RELNOTES=`@autovalue`, `@AutoAnnotation`, `@AutoOneOf`, and `@memoized` are now in a separate artifact, `auto-value-annotations`. This allows users to specify the annotations in compile scope and the processor in an annotation processing scope, without leaking the processor to a release binary. To upgrade to this version of auto-value, you'll need to add this new artifact as a dependency.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188505001
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment