Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sergei Ivanov
    @sergei-ivanov
    I am generally against adding extra features to the plugin for handling marginal cases. Usually it can be achieved by using the existing solutions. There must be a way to use maven-dependency-plugin to unpack the protos into the target directory in the early phase of the build lifecycle. And then point protobuf-maven-plugin to that directory as a source.
    I am currently typing from my phone, which makes it difficult to produce a proper example. But I hope you’ll be able to figure it out. If you are stuck, drop me a note here, and I may be able to help you later in the day. But try it yourself first please.
    thinkerou
    @thinkerou
    OK, thanks a lot, I will try it first!
    thinkerou
    @thinkerou
    @sergei-ivanov use maven-dependency-plugin can solve my question, thanks again!
    Sergei Ivanov
    @sergei-ivanov
    No worries, I am glad that I could point you in the right direction.
    Have a nice day!
    Wenwei Hu
    @wenweihu86
    <plugin>
    <groupId>org.xolstice.maven.plugins</groupId>
    <artifactId>protobuf-maven-plugin</artifactId>
    <version>0.6.1</version>
    <configuration>
    <clearOutputDirectory>false</clearOutputDirectory>
    </configuration>
    <executions>
    <execution>
    <goals>
    <goal>compile</goal>
    <goal>test-compile</goal>
    </goals>
    </execution>
    </executions>
    <dependencies>
    <dependency>
    <groupId>com.google.protobuf</groupId>
    <artifactId>protobuf-java</artifactId>
    <version>2.5.0</version>
    </dependency>
    </dependencies>
    </plugin>
    Import "google/protobuf/descriptor.proto" was not found or had errors.
    Sergei Ivanov
    @sergei-ivanov
    Hi. Can you check that the jar file has descriptor.proto packaged inside?
    2.5.0 is a very old version of protobuf library
    Eric Fulton
    @Sahasrara
    Hey there
    I want to have a server and a client package and I want both to somehow share a proto. Can protobuf-maven-plugin generate proto from a proto-only maven package?
    Sergei Ivanov
    @sergei-ivanov
    Hi
    It’s not a typical way of doing it. Usually the sources are generated in the same project/module that defines the proto files.
    Sergei Ivanov
    @sergei-ivanov
    You can work around it by using maven-dependency-plugin to unpack protos from the dependency artifact into your current project and them feed them in as a proto source.
    I think there was an example of doing it somewhere in the old issues in the plugin repo on GitHub. Try searching for it.
    Sergei Ivanov
    @sergei-ivanov
    The main problem is that protobuf-maven-plugin already scans the dependencies for proto files, unpacks them and uses them as imports for the protos in the current project. Using the dependencies as sources would potentially create a lot of confusion and complicate the plugin configuration.
    Sergei Ivanov
    @sergei-ivanov
    The best option is to co-locate the protos and the generated java sources/classes in the same project. Client- or server-specific dependencies can be declared as optional there to stop them propagating automatically.
    Franz van Betteraey
    @FrVaBe
    Hi,
    I noticed that the <attachDescriptorSet> option in version 0.6.1 is not used and probably the <writeDescriptorSet> option is used to decide if the descriptorSet will also be attached (https://github.com/xolstice/protobuf-maven-plugin/blob/46710107b0f966b8d4108871acd872718cb80a05/src/main/java/org/xolstice/maven/plugin/protobuf/AbstractProtocCompileMojo.java#L74). I my case writing the descriptor set causes the original jar not to be written unless I also define a classifier for the DescrptorSet artifact. However I guess this will not be fixed because the 0.7.0-SNAPSHOT version seems to put the DescriptorSet handling in an own goal. Is that right and whenwhen will the 0.7.0 version be available?
    Thank you for your commitment and best regards
    Franz
    Sergei Ivanov
    @sergei-ivanov
    Hi
    Sorry for a slow response, I have a lot going on at the moment. The future release is going to have a large number of breaking changes, and factoring out descriptor set functionality was one of them. It was a very early feature that we implemented before the number of goals started exploding, that's why it was originally bolted onto the existing goal. And shortly after we implemented it, we stopped using it and wrote our custom protoc plugin in java instead :)
    Sergei Ivanov
    @sergei-ivanov
    I think what you've found was a genuine bug, but as I was saying, not many people were using that functionality, so it remained undetected for about 7-8 years.
    Please bear with me, I have a few pending requests for version 0.7, but I'll try to release it soon.
    I am trying to pack as many long-standing breaking changes into this release as I can, so that the next releases are more incremental.
    Franz van Betteraey
    @FrVaBe
    @sergei-ivanov Sergei,
    I thank you for your work and the free provision of the plugin and don't want to stress you ;-) First of all I am glad that you answered my questions. The possibility to generate the FileDescriptorSet (with comments and dependencies) is very important for me. It would be a shame if this functionality would be lost. It would be great if the FileDescriptorSet file could not only be deployed as a separate artifact, but could also be embedded in the main jar (like the proto files). By now I have to do this with the build-helper-maven-plugin but would be nice to have this option also provided by your plugin. Keep up the good work, but keep calm. :thumbsup:
    Sergei Ivanov
    @sergei-ivanov
    No, the functionality definitely stays there, albeit repackaged. But you must be one of the very few users who actually use it, so your opinion is important. I checked last night, and the attach flag for descriptor sets is still broken in the latest code (now it always attaches it). I’m going to fix that.
    What is your use case for embedding the descriptor set?
    Franz van Betteraey
    @FrVaBe

    I work on a project with multiple services and multiple "protobuf datamodel" artifacts (we normally use a separat artifact to describe datastructures with protobuf which than can be used from all modules that need to work with this datastructure). The "overall project datamodel" is the sum of all datamodel artifacts and has to be documented. Thus I somehow will generate the documentation (which icludes the proto and the filedescriptor files) from the information included in the datamodel artifacts - and it just seems more practicall for me if all information is included in the main jar and I do not have to look for another artifact. Much the same argument as why you put the ".proto" files in the main artifact and not in a separate one I guess.

    Also, if a component depends on an "datamodel" artifact it has all information in place to handle ProtoBuf messages wether with the generated mapping classes or more generic with the usage of the embedded FileDescriptorSet and the DynamicMessage approach.

    Eric Fulton
    @Sahasrara
    Hey there, I'm running into an issue where the descriptor set is uploaded twice during a deploy causing a failure
    anyone else have that issue
    Also I guess attachDescriptorSet isn't functioning
    oh i see someone else had that issue.
    Eric Fulton
    @Sahasrara
    But yeah, my problem is different because the plugin attempts to upload the descriptor set twice which is causing deploy failures
    Eric Fulton
    @Sahasrara
    @sergei-ivanov let me know if I should file a bug, or if it's already a known issue.
    Sergei Ivanov
    @sergei-ivanov
    There must be two plugin invocations in your lifecycle which are both configured to generate a descriptor set. That is my guess, but I’d need to see your POM and maven command line to confirm.
    I’ll fix the attach flag in the next release. At the moment my main project is going through its death march phase, and because of that I cannot dedicate enough resources to the plugin. But I promise I’ll fix it as soon as I have time.
    Franz van Betteraey
    @FrVaBe
    @Sahasrara I had the same issue as you and use two separate executions now, one with writeDescriptorSet=trueand the other with writeDescriptorSet=false; as for example like this:
    <plugin>
        <groupId>org.xolstice.maven.plugins</groupId>
        <artifactId>protobuf-maven-plugin</artifactId>
        <!-- common configuration for all executions -->
        <configuration>
            <clearOutputDirectory>false</clearOutputDirectory>
            <protocArtifact>com.google.protobuf:protoc:${protobuf.version}:exe:${os.detected.classifier}</protocArtifact>
        </configuration>
        <executions>
            <!-- execution to compile the proto files without grpc plugin; also attach '*.proto' files
                and generate DescriptorSet file ('*.protobin') (must be done only once because otherwise it will
                be attached twice to the build and the double 'deploy' of the same protobin artifact fails) -->
            <execution>
                <id>protobuf-compile</id>
                <phase>generate-sources</phase>
                <goals>
                    <goal>compile</goal>
                </goals>
                <configuration>
                    <attachProtoSources>true</attachProtoSources>
                    <writeDescriptorSet>true</writeDescriptorSet>
                    <includeSourceInfoInDescriptorSet>true</includeSourceInfoInDescriptorSet>
                    <includeDependenciesInDescriptorSet>true</includeDependenciesInDescriptorSet>
                    <attachDescriptorSet>true</attachDescriptorSet>
                    <descriptorSetClassifier>descriptorSet</descriptorSetClassifier>
                </configuration>
            </execution>
            <!-- execution to compile the proto files with the grpc plugin -->
            <execution>
                <id>protobuf-compile-custom</id>
                <phase>generate-sources</phase>
                <goals>
                    <goal>compile-custom</goal>
                </goals>
                <configuration>
                    <attachProtoSources>false</attachProtoSources>
                    <writeDescriptorSet>false</writeDescriptorSet>
                    <pluginId>grpc-java</pluginId>
                    <pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
                </configuration>
            </execution>
        </executions>
    </plugin>
    Sergei Ivanov
    @sergei-ivanov
    I have fixed it on master as well
    Nadav Samet
    @thesamet
    Hey friends, I am the author of a library called ScalaPB (protobuf code generator for Scala). I want to provide an example project that shows how to use ScalaPB as a Java-based generator through protobuf-maven-plugin. I was able to do that, but I am looking for a way to inhibit Java code generation - so only the ScalaPB plugin gets invoked (in other words, I don't want --java_out to be passed to protoc). How do I go about that?
    Nadav Samet
    @thesamet
    Also, how do I pass parameters to the plugin, so it becomes --scalapb_out=param1,param2:... ?
    Sergei Ivanov
    @sergei-ivanov
    Hi, is your code generator java-based or native?
    Nadav Samet
    @thesamet
    It is java based
    Sergei Ivanov
    @sergei-ivanov
    ok, I think the current functionality for java-based plugins is tied to compile-java goal
    Sergei Ivanov
    @sergei-ivanov
    I think your issue vaguely relates to this one: xolstice/protobuf-maven-plugin#56
    I'll try to address that at some point
    bfmyr4
    @bfmyr4
    For csharp, the root namespace can be specified by "--csharp_opt=base_namespace=" on the protoc command line. Is there a way to specify that in pom? Otherwise csharp in generated-sources is flat and has no directory structure.
    Sergei Ivanov
    @sergei-ivanov
    @bfmyr4 I think your case will be covered by xolstice/protobuf-maven-plugin#56
    Looks like the additional parameter syntax has been adopted by almost all bundled protoc compiler plugins
    bfmyr4
    @bfmyr4
    I must be missing something. I just want to use the built in compile-csharp goal. Something like this doesn't seem to work. Example:
    <plugin>
    <groupId>org.xolstice.maven.plugins</groupId>
    <artifactId>protobuf-maven-plugin</artifactId>
    <version>0.6.1</version>
    <executions>
    <execution>
    <id>java</id>
    <goals>
    <goal>compile</goal>
    <goal>test-compile</goal>
    </goals>
    </execution>
    <execution>
    <id>csharp</id>
    <goals>
    <goal>compile-csharp</goal>
    </goals>
    <configuration>
    <pluginParameter>--csharp_opt=base_namespace=Com</pluginParameter>
    <protocArtifact>com.google.protobuf:protoc:3.7.1:exe:${os.detected.classifier}</protocArtifact>
    <attachProtoSources>false</attachProtoSources>
    <useArgumentFile>true</useArgumentFile>
    </configuration>
    </execution>
    </executions>
    <configuration>
    <protocArtifact>com.google.protobuf:protoc:3.7.1:exe:${os.detected.classifier}</protocArtifact>
    <attachProtoSources>false</attachProtoSources>
    <useArgumentFile>true</useArgumentFile>
    </configuration>
    </plugin>
    Sergei Ivanov
    @sergei-ivanov
    can you please create a separate ticket for that, I'll take a look when I have a chance