Hi everyone, I already posted this in the general channel but was hoping to get some feedback from h...

# coroutines

[marcoferrer]

Hi everyone, I already posted this in the general channel but was hoping to get some feedback from here since there is an entire coroutine based component to this project.

I put together a code generator that bridges coroutines with gRPC service methods. Providing suspending rpc calls without using listenable futures as well as rpc streams via channels. Any feedback is really appreciated as this is my first publicly released project

https://github.com/marcoferrer/kroto-plus

[lifk]

woah that sounds really cool, in my team we are working with grpc and kotlin and I thought in the past of doing something similar. I will take a deeper look one of this days to give feedback 😄

[marcoferrer]

Im in the middle of adding support for external code generators so users can generate code specific to their business domain. Also in the process of maturing the gradle plugin and preparing a release on maven central and sonatype snapshots. I would love to hear your feedback once you get a chance to give it a try. We’ve had good results using it internally at my job

[lifk]

I took note of it to try it out as soon as I'm back from holidays 😉

[gildor]

Nice! I thought about something similar just for education purposes (I don’t use grpc myself, but interested by approach itself).

Will take a look!
Just small question. Maybe generatedOutputDir configuration could be moved to your gradle plugin. At least some default output dir

[gildor]

Probably you should add “Publish gradle plugin to plugins.gradle.org” it will allow to use your plugin with plugins{} block instead of buildscript

[marcoferrer]

That’s a good point! I’ll add a note to get the plugin published on gradle.org. As for generatedOutputDir, I already have a defaultOutput option in the config block for krotoPlus. I was only trying to demonstrate how each individual generator can override the default and have its own output path. If it’s confusing I can try to change it around so it a little more obvious that’s it’s optional.

[marcoferrer]

Looking back I think you mean moving the clean and sourceset stuff to the plugin in which case your right. That should get pulled from the build script and into the plugin

[rocketraman]

Nice! I'm going to check this out too.

[lifk]

do you plan to add support to https://developers.google.com/protocol-buffers/docs/reference/google.protobuf messages so I don't get an error message like Failed to locate google/protobuf/struct.proto ?
I can add them manually to the sources in the gradle config but I think those types normally come with the proto compiler so I don't have them in my protos repo

[lifk]

also if I add them manually I don't seem to get a builder generated for them

[lifk]

actually I just saw that I can get them from build/extracted-include-protos/main as the protobuf gradle plugin puts them there