Using scalaPB with the canonical compiler plugin interface and/or protobuf-gradle

[Steven Ruppert]

Hi,

I'm trying to get scalaPB to work with a gradle-based project (for various reasons, I can't use SBT). The official protobuf plugin [0] does the work to call out to the `protoc` executable, and also lets you add codegen plugins throught the STDIN/OUT interface, e.g. the grpc codegen.

However, after poking through the scalaPB code, there doesn't appear to be an obvious way to plug into that interface. AFAICT, `protoc-bridge` runs a JVM process that calls a protoc subprocess, which calls back into the jvm plugin process. Is there an existing way to invert that control, e.g. some sort of `exec java -jar ...` script wrapper, or would I need to dig deeper to get this marriage to work?

I'm pretty sure I can just call `scalapbc` directly from a custom gradle task to Do What I Want To Do, but it doesn't seem quite as nice.

[0]: https://github.com/google/protobuf-gradle-plugin

[Nadav Samet]

Hi Steven,

Looks like you have a good idea already of the available options. I am not familiar with Gradle, but two approaches you can try:

1. Make protobuf-gradle-plugin invoke scalapbc instead of protoc (by setting protobuf.protoc.path), then set scala_out=...

2. Create a new gradle plugin that uses PluginFrontend from protoc-bridge to get a plugin path then passes it to protobuf-gradle-plugin

CONFIDENTIALITY NOTICE: This email message, and any documents, files or previous e-mail messages attached to it is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+unsubscribe@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/fb6f28fd-a74e-4d0e-9711-ab19ef7ac96e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-Nadav

[Steven Ruppert]

Hi Nadav,

Thanks for the response. After looking more closely at protocbridge,
I'm still confused about why it works the way it does.

The provided binary on https://github.com/scalapb/ScalaPB/releases is
a standalone `scalapbc` script, which launches the jvm, which then
launches a subprocess of the actual protoc compiler (from inside a
jar), which communicates back to its parent process through some fifo
redirection.

What I expected instead is a `gen-protoc-scala` script which, when put
on the PATH or passed to `protoc --plugin=gen-protoc-scala`, will
accept the codegen request on System.in, and exits after outputting to
System.out. In other words, `scalapbc` runs `protoc` for you, with no
(apparent) way to instead have your own copy of protoc call into
`scalapbc`. Roughly speaking, something like:

```
object main {
def main(args: Array[String]): Unit = {
val req = CodeGeneratorRequest.parseFrom(System.in)
val res = ProtocCodegenerator.run(req)
res.writeTo(System.out)
}
}
```

and `gen-protoc-scala`:

```
#/usr/bin/env bash
exec java -jar scalapb.jar
```

Is there a particular problem that the indirection of protocbridge and
the `scalapbc` wrapper works around? I scanned through the issues and
commits but nothing stood out.

Thanks,
Steven

>> email to scalapb+u...@googlegroups.com.

>> To post to this group, send email to sca...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/scalapb/fb6f28fd-a74e-4d0e-9711-ab19ef7ac96e%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> -Nadav

--
*CONFIDENTIALITY NOTICE: This email message, and any documents, files or

previous e-mail messages attached to it is for the sole use of the intended
recipient(s) and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply email

and destroy all copies of the original message.*

[Nadav Samet]

The approach you describe should work, we can even ship something like this with scalapbc. We wanted to achieve a solution that will include protoc in it, and also spare an instantiation of a second JVM.

>> email to scalapb+unsubscribe@googlegroups.com.

>> To post to this group, send email to sca...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/scalapb/fb6f28fd-a74e-4d0e-9711-ab19ef7ac96e%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> -Nadav

--
*CONFIDENTIALITY NOTICE: This email message, and any documents, files or
previous e-mail messages attached to it is for the sole use of the intended
recipient(s) and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply email
and destroy all copies of the original message.*

--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+unsubscribe@googlegroups.com.

To post to this group, send email to sca...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/CAKE1M7Z6aTt-nG2bpUFd%3DeoiuUk%2BXq_s1uYARzN5yK9qerbE-Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

-Nadav