Add support to configure proto plugin import paths.

[hsyed]

Real world mono-repos need to setup proto imports when using the Intellij proto plugin. The import paths are usually local workspace relative / in external repos. Some example of core proto imports are:

1. The WKT's from Protobuf core.
2. Plugin and descriptors for code generations from Protobuf core.
3. Google HTTP annotations used by grpc-gateway and for building google api's.
4. Gogo annotations for go projects.

[hsyed]

I had a PR open that implemented support but since it was not getting any traction I closed it.

The PR added support to add import paths to the project views which then then configure the proto plugin with the correct file system paths on sync.

The PR implements this in a separate directory called contrib which Is modelled as a distinct plugin, the dependency on the proto plugin is optional.

I'm happy to reopen this PR as I have some time on my hands at the moment.

[ittaiz]

This is using transitive_proto_path_flags <bazelbuild/bazel@98ed9af> from bazelbuild/bazel#4544 ?

…

On Mon, Aug 6, 2018 at 3:55 PM Hassan Syed ***@***.***> wrote: I had a PR open that implemented support but since it was not getting any traction I closed it. The PR implemented this in a seperate directory called contrib which Is modelled as a distinct plugin, the dependency on the proto plugin is optional. I'm happy to reopen this PR as I have some time on my hands at the moment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#384 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF5p4_f-XwhW5saztGumy9cBBzJ6rks5uODy4gaJpZM4VwVI7> .

[hsyed]

@ittaiz No I didn't look into harvesting anything from the sync model built by the plugin I kept it simple. There is a simple syntax for declaring the directory to add to the import path - it uses bazel labelling syntax to declare the directory to add to the path see.

This approach just works for most use-cases I have worked with (includes all of those mentioned above). Vendored go code directories can be easily picked up with a local workspace reference (gogo / kubernetes, grpc-gateway), the WKT's from com_google_protobuf can be easily added when working in exclusively a non-go project.

If we automate the population of the plugin collisions will be quite numerous in sizeable mono repos I suspect. Keeping in mind that the plugin is configured project wide -- we would need to write heuristics to break ties -- not that hard to do as in most cases selecting either of the import paths from a collision should be fine for code completion purposes, we will probably find use-cases where we need to override the collision resolution and this would be overkill.

[efeller]

@hsyed @ittaiz Thanks for contributing this. We would find it useful to merge this PR as well here.

[liucijus]

Related issue #2979