Really sorry for the cheesy title. No Game of Thrones jokes below. Promise. So, you’re using . Maybe because you had a monorepo before. Or maybe you just decided that you have too many modules in your Android project. Or just because it was hard to manage all those microservices you had in your neatly separated repos on GitHub. It doesn’t matter. Now you stuck with Bazel. Bazel One of the things you’ve lost the moment you switched to Bazel was rich ecosystem of plugins that tools like Maven and Gradle provided. Moreover, Gradle also allowed you writing DSLs and even custom tasks in Kotlin. All that goodness gone for good? Maybe not. Let’s see how we can take one Gradle plugin, in our case, and make it work with Bazel. KrotoPlus Before we start, let’s have a few words about KrotoPlus plugin and in general. gRPC All gRPC libraries take files as input and output three kinds of classes in your language of choice: .proto Messages Clients Server interfaces are just your plain data objects, for the sake of this discussion. They would have some fields, and those fields would have types. That’s all you need to know for now. Messages , also called stubs, are what you use to call your gRPC service. To create a client you would usually specify the host and port of your gRPC server, and then you would call a method, passing it your of choice. Clients message Servers implement generated and then begin to listen on the correct host and port to be able to serve clients. server interfaces What you need to take out of this is the follows: gRPC Library: (generated classes) ( ) => proto files Gradle likes to work with a well defined project structure, namely: your-gradle-project
  src
    main
      proto When you run your Gradle plugin and it “simply works”, that’s because Gradle was smart enough to recognise your and apply plugins to them. Source Sets So, in case you had some files in your directory, our Gradle plugin would detect them, and then generate some Java and Kotlin files in build directory: .proto proto your-gradle-project
  build <-- your generated files will appear there
  src
    main
      proto Bazel, on the other hand, knows nothing of that neat structure. Moreover, your files would be located outside of directory, like so: proto your-gradle-project some-proto-project
   proto <-- some proto files
...
your-gradle-project
  src
    main
      proto <-- empty
...
other-proto-project
  api
    proto <-- more proto files What we would like to do is to use our Gradle project sitting under Bazel as a function, that would get path to files, as if they were part of its Source Set, and then generate classes based on those files. .proto There are a few ways to achieve the behavior with Gradle, but here’s one of them: com.google.protobuf.gradle.*
...
protobuf {
    ...
    generatedFilesBaseDir = ...
    dependencies {
        protobuf(files(project.properties[ ].toString()))
    }
    generateProtoTasks {
        ...
    }
} import " /generated-sources" $buildDir "protoDir" The important part is the block. Here, instead of hardcoding our dependencies as we usually do, we get them from command line: dependencies project.properties[ ].toString() "protoDir" What that means is that when we run our Gradle wrapper, we now pass relative path to the files: .proto ./gradlew generateProto -PprotoDir=../path/to/protos Our Gradle is good and ready to go now. Next, let’s start working with Bazel. One of your main tools when you want to hack with Bazel will be . genrule This is your basic way to express that you would like to run something in Bash shell. But what’s that “something”? It should be , same wrapper we used before. But the problem is, Bazel is not aware of it. gradlew So, let’s create a file called in the same directory your is, and add the following block: BUILD gradlew filegroup(
    name = ,
    srcs = [ ],
) "gradle" "gradlew" That way we tell Bazel: hey, that’s a new file you should be aware of. But if you try to run it like that, Gradle would complain that it can’t find its configuration. That’s because we only told Bazel to copy to its sandbox, not anything else. gradlew Let’s fix that by adding another that would hold the configurations: filegroup filegroup(
    name = ,
    srcs = [ , , ]
            + glob([ ])
            + glob([ ]),
    visibility = [ ]
) "gradle_config" "build.gradle.kts" "krotoPlusConfig.asciipb" "settings.gradle" "gradle/**/*" "scripts/**/*" "//visibility:public" As you can see, we grab , as well as configurations files for KrotoPlus, and Gradle wrapper itself, which is located under directory. build.gradle.kts /gradle Now, to the rule itself. At first, it will look intimidating, but we’ll break it line by line. genrule(
    name = ,
    cmd = ,
    outs = [ ],
    message = ,
    srcs = [],
    tools = [ ] + [ ],
) "run_gradle" """
    ./$(location gradlew) -p $$(dirname ./$(location gradlew)) generateProto -PprotoDir=../proto/ &&
    cp -R $$(dirname ./$(location gradlew))/build/generated-sources  $(@D)
    """ "build/generated-sources" "Generating protos" ":gradle" ":gradle_config" is the label you want to refer to when specifying dependency of your library. name is the command that would run inside the shell. We’ll break it down later cmd is what this command produces. Bazel tries to track every output of your script, so you need to tell it what you expect to change in the filesystem after you execute cmd. If directory build/generated-sources is not changed, Bazel will complain. outs is what will be displayed while you wait message are the input files you would like to run your script on. Ideally, those would be your files. But in this case, we’ll leave them empty, as we use instead srcs .proto -PprotoDir is the list of files you need to use to produce the output. In our case, it’s the Gradle Wrapper and all the configurations. tools Now let’s go back to and understand what’s going on inside. cmd When you start Bazel, its root is at file location, not the directory where is located. So, we use to expand label to its relative location. In our example, that would be something like WORKSPACE gradlew $(location gradlew) ./your-gradle-project Once we located the Gradle Wrapper executable, we need to tell it where to find its configuration. We do that with , that’s standard Gradle flag. We know that this directory is again relative to our , hence . But this time, it must be a directory, and location will expand to path to file, so we use . But Bazel already uses for . So we end up with screening the command: -p WORKSPACE ./$(location gradlew) $(dirname) $ $(location) $$(dirname) Once we located the configuration, we need to tell Gradle which task to run. That’s generateProto And now we need to point Gradle to the location of our files. But the context switches here, from Bazel to Gradle, so the path is relative to location now: .proto gradlew -PprotoDir=../proto/ Now Gradle and KrotoPlus work hard to generate our gRPC classes. The problem is, though, they’re generated in the Gradle directory, and not inside Bazel sandbox. So, we need to copy them. is a standard shell command, and we already covered what stands for. The only part you’re not familiar with yet, is cp -R $$dirname() $(@D) That’s the output directory we specified with , and as a result, copies generated files where we want them to be. outs Conclusions and next steps Combining Bazel and Gradle to generate files is possible, if a bit cumbersome. If you want to go down that path, your next steps should be: Remember to cleanup after yourself. would be nice rm -rf $$gradleDir/build You probably want to make a function out of this . Syntax stays almost the same, but you need to prefix with when inside a function: genrule genrule native native.genrule In the long run, using relative paths as we did with isn’t the right choice. Although it’s useful for testing KrotoPlus plugins. Better choice would be to rely on labels. -PprotoDir Hopefully, if you’re already using Bazel, this article will set you on the right track.

Google

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Gradle, Bazel and gRPC: A Song of Ice and Fire

Too Long; Didn't Read

Company Mentioned

Alexey Soshin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Gradle, Bazel and gRPC: A Song of Ice and Fire

Too Long; Didn't Read

Company Mentioned

Alexey Soshin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES