Auto-configure *.proto paths from project dependencies

[jmpicnic]

I have a project, using Kotlin/Gradle that has the following dependency:

implementation("com.google.api.grpc:proto-google-common-protos:1.16.0")

if I configure the path to the sources jar file in the Preferences --> Protocol Buffers as:

jar:///<...PATH TO HOME>/.gradle/caches/modules-2/files-2.1/com.google.api.grpc/proto-google-common-protos/1.16.0/bdc28414cdd1f5003c2fdcc59c7f597c2da5b1b1/proto-google-common-protos-1.16.0-sources.jar!/

The Plug-In finds the proto files and correctly resolves the imports.

Is there a way to have the plug-in pick up protofiles from the Gradle dependencies (or IntelliJ project libraries) using "AutoConfigure"?

The option to manually configure will not quite work as it requires the local path to the jar file, and that changes from developer to developer.

Any ideas would be most welcome.

Miguel

[devkanro]

See the discusses in #29

Before @jvolkman refactored the FileResolveProvider and ProjectSettingsConfigurator, you can download the modified plugin and install it from disk.

protobuf-editor-with-library-support.zip

[jedvardsson]

First of all: Great plugin! It would be even better with some minor adjustments to the automatic configuration for import paths. While the plugin could scan dependencies for protos as suggested by @jmpicnic an easier fix would be to automatically add target/classes, target/test-classes and target/protoc-dependencies/* to the path (perhaps instead of src/main/resources and src/test/resources). This provides more flexibility for the user.

For example, we use the org.xolstice.maven.plugins:protobuf-maven-plugin. Out of the box this plugin scans for protos under src/main/proto and not under src/main/resources. However, all compiled protos are placed under target/classes.

The protobuf-maven-plugin also extracts all protofiles from dependencies and places them under target/protoc-dependencies. In the default format of this directory (there are two formats) proto files in jars are extracted into a directory named after a hash of the jar-file coordinates. For example, in my project I have:

$ ls -1 target/protoc-dependencies/
dfe3f0c820d089b4b01e46cdbdb0fb99
fa7cb8ace8a6b7306ff4f6ee3c13898a

Which corresponds to com.google.api.grpc:proto-google-common-protos:jar:1.17.0 and com.google.protobuf:protobuf-java:jar:3.13.0. The plugin could automatically add these directories too.

target/protoc-dependencies/fa7cb8ace8a6b7306ff4f6ee3c13898a/google/protobuf/timestamp.proto
target/protoc-dependencies/fa7cb8ace8a6b7306ff4f6ee3c13898a/google/protobuf/field_mask.proto
target/protoc-dependencies/fa7cb8ace8a6b7306ff4f6ee3c13898a/google/protobuf/api.proto
...

What do you think?

[ToQuery]

I am using this way to date files of dependent items

jar:///<...PATH TO HOME>/.gradle/caches/modules-2/files-2.1/com.google.api.grpc/proto-google-common-protos/1.16.0/bdc28414cdd1f5003c2fdcc59c7f597c2da5b1b1/proto-google-common-protos-1.16.0-sources.jar!/

it is working.

But every time the version of the dependent project changes, I must configure it again.

When will it happen “Auto-configure *.proto paths from project dependencies” ？

[junzebao]

We're also using the org.xolstice.maven.plugins:protobuf-maven-plugin plugin to automatically resolve dependencies as @jedvardsson mentioned. It would be great if the plugin could consider this case.

[devkanro]

@jvolkman said he will refactor the file resolver, but there are no updates after many months.

I really need this feature for our team, so I built a new plugin for improving development experience with protobuf for Java Project.

And I just make the plugin public now, if you use the protos in Jar same as me, you can try this plugin.