Skip to content
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

Gradle 5.x #330

Merged
merged 29 commits into from
Apr 2, 2019
Merged

Gradle 5.x #330

merged 29 commits into from
Apr 2, 2019

Conversation

ZacSweers
Copy link
Collaborator

Resolves #296

Note there's still some warnings about accessing compiler APIs, but that's internal to the error prone plugin. Will need to wait for tbroyer/gradle-errorprone-plugin#22

@ZacSweers ZacSweers self-assigned this Jan 26, 2019
@ZacSweers
Copy link
Collaborator Author

For the life of me I don't understand this lint/gradle error. Continues to happen even if I manually create that configuration too

@tbroyer
Copy link

tbroyer commented Jan 27, 2019

Fwiw, the warning in net.ltgt.errorprone is due to AGP 3.3, which you introduced in #326, not Gradle 5.

@ZacSweers
Copy link
Collaborator Author

Yep, I was just noting that they're coming from the plugin and not something we can completely resolve yet

@@ -1,5 +1,5 @@
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.2-all.zip
distributionUrl=https\://services.gradle.org/distributions/gradle-5.2.1-all.zip
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like they just released 5.3

@ZacSweers
Copy link
Collaborator Author

Now lint OOMs CI. -_-

@ZacSweers
Copy link
Collaborator Author

@lazaroclapp @msridhar any ideas about that NullAway wiring failure?

Caused by: java.lang.IllegalStateException: DO NOT report an issue to Error Prone for this crash!  NullAway configuration is incorrect.  Must specify annotated packages, using the -XepOpt:NullAway:AnnotatedPackages=[...] flag.  If you feel you have gotten this message in error report an issue at https://github.com/uber/NullAway/issues.
  	at com.uber.nullaway.ErrorProneCLIFlagsConfig.<init>(ErrorProneCLIFlagsConfig.java:112)
  	at com.uber.nullaway.NullAway.<init>(NullAway.java:236)
  	... 53 more

@tbroyer
Copy link

tbroyer commented Apr 1, 2019

Task :android:autodispose-android:compileDebugUnitTestJavaWithJavac FAILED

You changed from configuring every JavaCompile task to only configuring those from libraryVariants, so testVariants and unitTestVariants aren't configured.

@ZacSweers
Copy link
Collaborator Author

Yep just realized that in trying to repro this on the nullaway sample. Is there a way to disable nullaway for those variants though? I know only running a subset of error prone checks in tests is a pattern some projects use, but it seems like that may not be possible if it's always initialized just for being on the classpath

@tbroyer
Copy link

tbroyer commented Apr 1, 2019

Either only put NullAway in the classpath for non-test variants (annotationProcessor would likely work), or disable it in test variants, something like (using net.ltgt.errorprone 0.7.1)

afterEvaluate {
  tasks.withType(JavaCompile).configureEach {
    options.errorprone {
      if (compilingTestOnlyCode) {
        check("NullAway", CheckSeverity.OFF)
      }
    }
  }
}

(or alternatively using testVariants and unitTestVariants)

I would however configure NullAway:AnnotatedPackages on each and every task, and only change the check severity depending on whether this is a test task or not (or only put NullAway in the classpath where you want to use it). YMMV

@tbroyer
Copy link

tbroyer commented Apr 1, 2019

BTW (seeing your last commit), net.ltgt.nullaway would currently (v0.1) always pass -Xep:NullAway with a severity, so unless you use -XepIgnoreUnknownCheckNames this forces you to put NullAway in the classpath for all compile tasks. You could however use a provider to lazily compute the check severity depending on compilingTestOnlyCode:

tasks.withType(JavaCompile).configureEach {
  options.errorprone.nullaway.severity = provider { options.errorprone.compilingTestOnlyCode ? CheckSeverity.OFF : CheckSeverity.ERROR }
}

(Fwiw, I've just updated net.ltgt.errorprone to use lazy properties so you could use compilingTestOnlyCode.map { … } instead, but I have more API changes to do before cutting a new release)

@ZacSweers
Copy link
Collaborator Author

Yep I agree with putting it in every variant normally. Thanks for the example, continuing that thread in uber/NullAway#294

Unfortunately even if I manually wire this for each of those variants in 0916401, the error still comes up. Will dig in more as I'm not sure where else this could be configured unless DomainObjectSet#addAll is noop-ing for some reason.

@ZacSweers
Copy link
Collaborator Author

confirmed locally that DomainObjectSet#addAll was indeed not doing anything :|

@ZacSweers
Copy link
Collaborator Author

@shaishavgandhi05 want to re-review this since it's changed a fair bit now?

@ZacSweers
Copy link
Collaborator Author

I've also tweaked the travis CI settings to only run branch builds on master (for snapshots) and limit PR builds to just the single PR build type

compilationHelper.setArgs(ImmutableList.of("-XepOpt:TypesWithScope"
+ "=com.uber.autodispose.errorprone.ComponentWithLifecycle"));
compilationHelper.addSourceFile("UseAutoDisposeDefaultClassPositiveCases.java").doTest();
@Test
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the annotation on separate line? All other tests have it on the same line right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to start slowly transitioning this to GJF, started with this

@ZacSweers ZacSweers merged commit b6e8067 into master Apr 2, 2019
@ZacSweers ZacSweers deleted the z/gradle5 branch April 2, 2019 04:40
lazaroclapp pushed a commit to uber/NullAway that referenced this pull request Apr 8, 2019
Modernizes the android example with the new lazy task configuration APIs. Based on implementation figured out here: uber/AutoDispose#330
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants