Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B buck
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 201
    • Issues 201
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 22
    • Merge requests 22
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Meta
  • buck
  • Merge requests
  • !1987

Add annotation_processing_tool (kapt | javac) option to Kotlin modules

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Administrator requested to merge github/fork/lyft/az/annotation-processing-tool-kotlin into master Aug 02, 2018
  • Overview 26
  • Commits 11
  • Pipelines 0
  • Changes 21

Created by: artem-zinnatullin

Original motivation was explained in discussion in Slack:

Hey guys, after spending couple days on trying to switch us to Buck upstream I came to conclusion that kapt support needs to be changed in the upstream, kapt should be optional.

We have mixed Java/Kotlin modules where we deliberately run annotation processing only against Java sources (our reasoning is build speed & stability in both Buck and Gradle setups).

In our setup kapt is not enabled on the Gradle side

On the Buck side however kapt kicks in even if we don't ask for it, what's worse it becomes primary method of annotation processing for mixed modules.

We have 2 problems because of that:

  1. If module doesn't have any .kt with annotations that need apt, build fails because .zip with generated classes is not produced. Can be "solved" by converting one of the classes with annotations to Kotlin, but we don't need nor want that.

  2. Build will behave differently if we convert (see point №1) one of the classes to .kt, it'll work in Buck but won't work in Gradle because we don't use kapt there

I've dealt with it before by turning kapt off in our fork, but we really want to get on to the upstream Buck to move faster, and kapt support is last huge blocker I'm dealing with…

I think OkBuck could look for kapt configuration and only then enable kapt in Buck

@cwoodwar6 mentioned they have same problem:

To your first point, we face the same issue and have been putting simple stub kotlin files to work around it. But we don’t like this solution either and have looking to fix it


Techincal aspects of this PR:

PR adds a separate annotation_processing_tool = "kapt/javac" to the DSL of Kotlin modules.

Default value is kept as kapt for compatibility.

Tools:

  • kapt tool: Allows to run Java annotation processors against Kotlin sources while backporting it for Java sources too.
  • javac tool: Works only against Java sources, Kotlin sources won't have access to generated classes at compile time.

If this gets accepted, the next step will be to update OkBuck with respecting Gradle kapt vs annotationProcessor configurations.

cc @thalescm @cwoodwar6 @kageiit

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: github/fork/lyft/az/annotation-processing-tool-kotlin