Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Yaroslav Paramonov
    What's the default proto-path value on plugin?
    Sergei Ivanov
    Hi, sorry for the delay. The configuration above looks perfectly valid, and in your screenshot IDEA has correctly detected the generated-sources/protobuf/grpc-java as a source path. Or did you have to mark it as a source folder manually?
    Can you create a small project on GitHub to demonstrate the problem?
    Hello I have a question, I hope somebody could help me out...
    When I want to link to a proto folder outside of my eclipse project by adding the <protoSourceRoot> property to the plugin configuration Eclipse throws an error, although the plugin generates the sources just fine. But this makes checking if my project has build ok from the IDE very confusing...
    I am using Eclipse 2019-12 (4.14.0) with embedded maven 3.6.3
    My pom:
    It reports all plugin artifacts as missing... but maven does generate all the sources
    mmm so It does build the classes, but when I refresh the project it removes all the sources immidiately
    Sergei Ivanov
    Hi, looks like a known Eclipse issue
    take a look at this:
    yeah I already have this setup it works fine when my proto files are inside /src/main/proto
    Sergei Ivanov
    then it is an eclipse issue
    try raising it with them
    Eclipse is generally trying to be too smart with Maven integration, which does not always work
    Sergei Ivanov
    Unfortunately, I cannot offer any support for Eclipse integration. I am not an Eclipse user nor Eclipse developer. Most of the Eclipse support that we have in the plugin has been contributed by the community.
    it's just so weird that everyting works fine and somehow every things get's immediately removed after the build... i can't seem to find the source for this removal
    i'll raise it with eclipse people
    thank you sergei from the past!
    An thank you for your project!
    Sergei Ivanov
    You are welcome :)
    James Parker
    Has anyone had any experience using a documentation generator with this before? For example this one https://github.com/pseudomuto/protoc-gen-doc?
    Sergei Ivanov
    Looks pretty cool, I did not know about it. I guess it can be used like any other protoc plugin.
    David Bryson
    Hi, do I understand correctly that protobuf-maven-plugin can only use java based protoc plugins ?
    Trying to see if I can correctly incorporate plugins written in Go for example
    but the documentation is a bit murky here
    Sergei Ivanov
    Yes you can (this is how gRPC plugin is being used)
    Sergei Ivanov
    There are examples in the integration tests, but here I have a yet unpublished portion of the maven site with a POM snippet
    David Bryson
    ok great
    thank you

    Hello, I just started with the plugin as I am very interested in the possibility to solve my command line too long issue
    I configured the plugin with property <useArgumentFile>true</useArgumentFile> but apparently the file is not generated

    I ran mvn clean install with debug option and I can see:

    [INFO] Compiling 83 proto file(s) to C:\git_clones\XXXXX\XXXX\target\generated-sources\protobuf\java
    [DEBUG] [PROTOC] Using arguments file C:\git_clones\XXXXXX\XXXXXX\target\protoc504033337756143919.tmp
    [ERROR] PROTOC FAILED: The filename, directory name, or volume label syntax is incorrect.

    And actually the file is not where the log indicates it is

    Sergei Ivanov
    @Carboris sorry for a late reply. This looks a bit strange, because it should be working! There are integration tests that verify the argument file functionality on Windows too. Do you have spaces in your path or any non-latin characters? It will help to know a bit more about the system you are running it on.
    David Bryson
    I'm curious if someone could expand on why native plugin parameters cannot contain a colon ? I'm trying to use this plugin: https://buf.build/docs/lint-protoc-plugin but it passes arguments as a json structure
    or yaml, which means ':' is frequently used
    David Bryson
    For example, here is the output I am using by hand with this plugin:
    protoc -I={PROTOS_ROOT_DIR} --buf-check-lint_out=. '--buf-check-lint_opt={"input_config":{"lint":{"use":["STYLE_BASIC"], "except":["ONEOF_LOWER_SNAKE_CASE", "PACKAGE_LOWER_SNAKE_CASE"]}}}' $(find {PROTOS_ROOT_DIR} -name "*.proto")
    David Bryson
    still curious if anyone is familiar with why this restriction is in place ^^^^
    Sergei Ivanov
    Hi David. Sorry for a late answer, I was too busy in the last month. The reason is that historically there was two ways of passing the parameters to protoc plugins:
    1. As part of the plugin-specific xxx_out parameter. For example, it was used by JS plugin: --js_out=import_style=commonjs:<output directory>. Since colon was used to separate the parameters from the output path, it was not allowed as part of the parameter value.
    2. Then there came a new way of passing the options, like in --csharp_opt=base_namespace=Com. I am not sure if this way has been standardised by now, but I have a feeling that it's slowly becoming the preferred way. Unfortunately, there's no support for that in the maven plugin at the moment.
    Johnny Nilsson

    I recon the question might already have been asked, but I am new here and can't find my way around well enough to find the answers.

    We are building our project on both windows and linux machines and would want to use the default protoc command when executing the build.

    However, I am on a quest to remove the warning that pops up if you don't configure the <protocExecutable>.
    Is this possible? It seems it should be logged as info instead of a warning, really.

    Sergei Ivanov
    Hi, @Nadrendion Sorry, I am currently in a "slow response" mode.
    The main goal behind some early changes in the plugin was to make the builds predictable and ideally OS-independent. Before those changes using protoc from the $PATH was the only option available, and that caused a lot of inconsistency between the developer builds and CI builds (and building on different OSes). That's why it's a warning. It basically says: "if you are using system protoc, you are running the risk of getting inconsistent results".
    What stops you from using the official protoc binaries that are distributed through Maven Central, and which are fully supported by the plugin?
    Ryan Hansen

    Hey there, I have a feeling the answer is "no" given lack of finding anything through search but figured I'd ask anyway. Does this plugin support the ability to only generate client stubs or is this always all-or-nothing?

    I ask because my use-case is in-line with that of SDK development. I want to make the proto files available publicly and will offer pre-canned client implementations for a few different tech stacks initially. However; giving my clients the proto files would be enough to make their life easier if they wanted a client for a stack that I have not yet published.

    In addition to this, I will be implementing the service contract within a project that is housed within a private repository. It would not be proper to have that implementation packaged with the client implementation.

    Sergei Ivanov
    Hi @hanserya
    I think I'll need an example to understand your case better and figure out the gaps in the current implementation.
    pranay jain
    Hi @sergei-ivanov , I was curios if there is a way to generate different protocol descriptor set for different proto file in the same project. Basically, I have a common project which contains proto files for all of the services. I need to generate descriptor set for the proto files separately. If yes, it would be great if you could redirect me to specific example
    Sean Farrow
    Hi all, I've just found this plugin and it looks like it will do what I want. However I can't find a way to tell the plugin my proto files are in the root directory of the project. Can anyone help?