aboutsummaryrefslogtreecommitdiff
path: root/service/processor
AgeCommit message (Collapse)Author
2021-07-02Internal changedependabot[bot]
PiperOrigin-RevId: 382739421
2021-06-02Reformat all the Auto projects using google-java-format. For now, javadoc ↵Éamonn McManus
reformatting is excluded. RELNOTES=n/a PiperOrigin-RevId: 377145832
2021-06-01Upgrade dependencies to auto-common 1.0.1 and replace Guava toImmutable* ↵Brad Corso
usages with auto-common alternatives. This fixes an issue that occurs when the Android flavor of Guava somehow finds its way onto the processor class path and gets classloaded instead of the server Guava. The ideal solution would be to just keep the Android flavor of Guava off of the processor class path. However, it's been something that we've allowed for a while now, e.g. in Dagger, and would be difficult to start enforcing. RELNOTES=N/A PiperOrigin-RevId: 376926489
2021-05-25Use the return value of `addAll()` instead of making separate calls to ↵David P. Baker
`containsAll()` and `addAll()`. RELNOTES=n/a PiperOrigin-RevId: 375727307
2021-05-25Continue rather than returning in the AutoService loop.Éamonn McManus
The old code would return as soon as it found a `META-INF/services` file that contributed nothing to the list of services to be generated. It should have continued instead, to go on to the next provider interface. Fixes https://github.com/google/auto/issues/839. Thanks to @bbyk for the bug report. RELNOTES=Fixed a bug in AutoServiceProcessor that could lead to some services not being processed. PiperOrigin-RevId: 375717338
2021-04-06Update dependencies on Auto Common from 0.11 to 1.0.Éamonn McManus
RELNOTES=n/a PiperOrigin-RevId: 367066911
2020-12-08Allow `@AutoService` to reference a generic service even if `-Averify=true`.Éamonn McManus
Previously we allowed this without `-Averify`, but produced an error if `-Averify=true`. Now, that error becomes a warning, and can be suppressed outright with `@SuppressWarnings("rawtypes")`. The fundamental issue is that when you say `@AutoService(MyService.class)`, there is no way to specify a type parameter, even if both `MyService` and the implementing class have one. This accurately reflects the limitation that `ServiceLoader.load(MyService.class)` doesn't include generics either. So there's some necessary imprecision in the type system, but it's not outright wrong the way it would be if you specified an unrelated type. Fixes https://github.com/google/auto/issues/870. Closes https://github.com/google/auto/pull/871. RELNOTES=`@AutoService` classes can now reference generic services and still pass `-Averify=true`. PiperOrigin-RevId: 346338973
2020-12-08Rewrite `AutoServiceProcessorTest` to use more modern Compile Testing APIs.Éamonn McManus
RELNOTES=n/a PiperOrigin-RevId: 346311927
2020-10-22Update a bunch of *deps* (though not *plugins*).cpovirk
Process: ( for F in common factory service value; do ( mvn org.codehaus.mojo:versions-maven-plugin:2.8.1:update-properties org.codehaus.mojo:versions-maven-plugin:2.8.1:use-latest-releases -f $F/pom.xml ); done && mvn org.codehaus.mojo:versions-maven-plugin:2.8.1:use-latest-versions -f value/src/it/gwtserializer/pom.xml ) Then undid the Compile-Testing update in value/pom.xml. It somehow breaks things. And I undid the google-java-format update in factory/pom.xml. It isn't compatible with JDK8/9, which is what Travis is set up for. (And then I flailed around for 15 minutes because Maven didn't rebuild some files when I changed JDKs, producing mystery failures. Argh. Perhaps we should set `<useIncrementalCompilation>` to `false` everywhere.) And *then* I undid the auto-service upgrade in value/processor/pom.xml. It causes problems but only under JDK9: https://travis-ci.org/github/google/auto/jobs/738096563 The error isn't in generated code, so I suspect a compiler bug. (But my quick search didn't find a filed OpenJDK issue.) (Someday I will remember -DgenerateBackupPoms=false....) For some reason, gwtserializer responds to use-latest-versions but not to use-latest-releases, even though it's updating GWT to a release (just as in one of the other POMs). We don't use use-latest-versions everywhere not just because it could theoretically pick a non-release versions but also because use-latest-versions replaces variable usages like ${guava-version} by inlining the value into them: https://github.com/mojohaus/versions-maven-plugin/issues/243 I would have updated the plugins in addition to the deps, but oddly the plugin does not support this: https://stackoverflow.com/q/34032262/28465 Fixes #919, #918, #917, #915, #914, #911, #908, #906, #904, #903, #901, #900, #899 RELNOTES=n/a PiperOrigin-RevId: 338507900
2020-10-18Don't claim annotations in AutoAnnotationProcessor and AutoServiceProcessor.Éamonn McManus
Annotation claiming is a misfeature and we already stopped doing it years ago in AutoValueProcessor. It's an oversight that we didn't do it for these processors at the same time. Also apply some automated code-fix suggestions. RELNOTES=AutoAnnotationProcessor and AutoServiceProcessor no longer claim their annotations. PiperOrigin-RevId: 337750292
2019-05-05Stop using auto-parent.cpovirk
It's released separately from all its children, so any updates we make there don't take effect until we make a release and update the child projects to use that. This requires pushing various configuration down into the child projects. Doing so makes the recent attempted update to Truth 0.44 actually take effect. Also, update Compile-Testing to the newly released version, which actually works with Truth 0.44. That upgrade exposes that AutoValue was relying on a transitive dependency on Truth8, which was removed in the latest Compile-Testing, so I've added explicit deps. https://github.com/google/compile-testing/commit/43a513ab14a5b4ab5810a13e14d8cb763546ab5d Also, I removed an explicit version for compile-testing in the AutoValue functional tests. That explicit version may or may not have been needed before, but it shouldn't be now. Likely it would make sense to remove more versions explicitly specified elsewhere. (Additional possible future work: Put deps on other Auto projects (like when AutoService depends on AutoCommon) into <dependencyManagement>.) Finally, I added some <url> values, since Maven has been generating bogus ones all along (by appending the subproject name to the parent URL, producing URLs something like "https://github.com/google/auto/auto-value"). ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=245779060
2019-04-29Update copyrights to say Google LLC instead of Google Inc.emcmanus
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=244250754
2019-04-03Set the nested AutoService pom's to have the same parent ↵ronshapiro
(auto-service-aggregator). This allows mvn versions:set to set each of them at the same time. It also allows them to be released in tandem. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=240976869
2019-04-03Move the META-INF/gradle resources into auto/service/processor.ronshapiro
I missed this when first doing the migration ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=240483232
2018-12-03Update to auto-parent 7 to get the latest version of Guavaronshapiro
Along the way, also clean up some explicit versions that are set in auto-parent Fixes https://github.com/google/auto/issues/683 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=223540267
2018-11-06Separate AutoService annotations and processorronshapiro
Fixes https://github.com/google/auto/issues/632 RELNOTES=`@AutoService` now has a separate artifact (`auto-service-annotations`) separate from the annotation processor (still `auto-service`) ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=219696198
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 22:46:01 +0000