Kotlin package name conflicting
Dogacel opened this issue · 4 comments
When using the Gradle plugin, I need to add a prefix to my package name (or change it) because it overlaps with kotlin {} builtin and without it, I can't use grpckt.
when I try option("kotlin_package=pbandk.example") it gives the error,
pbandk/example/types.kt: Tried to write the same file twice.
pbandk/example/enums.kt: Tried to write the same file twice.
seems like kotlin_package just overrides the proto package. But I want to add a suffix to porto package so it is something different from the default protoc generated packages. Otherwise imports are mixing up, grpc code tries to import from pbandk so it gives errors.
Is it possible to support something like package prefix?
There is an undocumented kotlin_package_mapping option to protoc-gen-pbandk that allows defining a custom mapping from proto package names to kotlin package names. E.g.:
option("kotlin_package_mapping=google.api->pbandk.google.api;google.rpc->pbandk.google.rpc")
Would that satisfy your use case? If not, your PR to add a prefix seems like a reasonable approach too. I just don't want to add another option if the existing option will work for you.
The implementation is here if you're curious:
Would that satisfy your use case?
There are hundreds of different packages because we use monorepo structure for our protos. So there are 20-30 different microservices, each having a different package name, and they are divided into multiple sub-packages.
From reading the code, what I understand is package mapping does not work for prefixes, e.g. I have com.example.v1, com.example.v2 packages and I want to map com.example to org.example. I should add 2 mappings containing the exact same package name such as
option("kotlin_package_mapping=com.example.v1->org.example.v1;com.example.v2->org.example.v2")
And I can't use
option("kotlin_package_mapping=com.example->org.example")
If I was able to use the latter, (which is similar to prefixing), I would be satisfied but maintaining the first solution is very tough in our case. Maybe we can extend it to support some wildcard matching, what do you think?
Example (Dots might cause some issues but I think if we only parse regex inside parentheses, we will be safe)
option("kotlin_package_mapping=com.example(.*)->org.example($0)")