Separate AutoValue Annotations and Processor into different dependencies.

rharter commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Also, +1 :grinning:

alangpierce commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/google/auto/issues/268#issuecomment-141759453.

mttkay commented 9 years ago

+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 9 years ago

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 commented 9 years ago

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 :+1: Although for our case I did not need the generated annotation.

mttkay commented 9 years ago

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: :+1:] Although for our case I did not need the generated annotation.

— Reply to this email directly or view it on GitHub https://github.com/google/auto/issues/268#issuecomment-143243732.

mttkay commented 9 years ago

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

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

JakeWharton commented 9 years ago

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 https://github.com/google/auto/issues/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 https://github.com/google/auto/issues/268#issuecomment-144668739.

mttkay commented 9 years ago

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 https://github.com/google/auto/issues/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 https://github.com/google/auto/issues/268#issuecomment-144668739.

— Reply to this email directly or view it on GitHub https://github.com/google/auto/issues/268#issuecomment-144747177.

CoatedMoose commented 9 years ago

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

cgruber commented 9 years ago

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 https://github.com/google/auto/issues/268#issuecomment-146669127.

artem-zinnatullin commented 8 years ago

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

eamonnmcmanus commented 8 years ago

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 commented 8 years ago

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

CoatedMoose commented 8 years ago

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.

ZacSweers commented 8 years ago

Can probably close this in favor of #374 now?

CoatedMoose commented 8 years ago

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 commented 8 years ago

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 https://github.com/google/auto/issues/268#issuecomment-246243562, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUN4gNBa9R4auix6jHQE3_CsWno-bKPks5qpNb9gaJpZM4F6ul7 .

bubenheimer commented 7 years ago

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 https://github.com/google/auto/issues/268#issuecomment-143242173 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@simtel12 Figured out any way to sort it out?

simtel12 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

tbroyer commented 7 years ago

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: https://github.com/google/auto/issues/268#issuecomment-199955649

tmtron commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 - https://github.com/google/auto/issues/268#issuecomment-335848521.

tasomaniac commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Madhuri98 commented 6 years ago

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

cpovirk commented 3 months ago

Reopening in light of https://github.com/google/auto/pull/352#issuecomment-2262161659

cpovirk commented 3 months ago

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

google / auto

Separate AutoValue Annotations and Processor into different dependencies. #268

264 would hide shaded dependencies from IDE autocompletion