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
    Are your other projects maven projects too?
    uruloki85
    @uruloki85
    Nope, they aren't. They are just 2 proto files designed by other people.
    Sergei Ivanov
    @sergei-ivanov
    But when you refer to ../project2/src/main/proto it looks like another maven project
    uruloki85
    @uruloki85
    But it isn't
    Sergei Ivanov
    @sergei-ivanov
    Ok, looks like it only pretends to be one then :)
    Duke Jake Morgan
    @TheMasteredPanda
    Anyone available to tend to my problem? xolstice/protobuf-maven-plugin#38
    Thanks in advance.
    Sergei Ivanov
    @sergei-ivanov
    I answered there
    bkuhhirte
    @bkuhhirte
    I just started using this plugin and curious if anyone else has tried to use it in conjunction protoc-gen-swagger?
    In other words, as I generate my stubs and unravel the dependent .proto files from other JARs, can I generate the swagger.json without going back to the CLI?
    Sergei Ivanov
    @sergei-ivanov
    Can you please provide any links or examples?
    Amal Janardhanan
    @amalj_twitter
    I have around 1000+ protobuf schema files. When I tried to compile, I am getting "/protoBufSchemas/target/protoc-plugins/protoc-3.0.2-osx-x86_64.exe": error=7, Argument list too long". Any help with this please ?
    Sergei Ivanov
    @sergei-ivanov
    The only way around it at the moment is to split up your plugin execution into a few smaller executions, each using includes and excludes to compile a smaller chunk of proto files at a time.
    Sergei Ivanov
    @sergei-ivanov
    @amalj_twitter there is a pending PR that will address this issue for protoc version 3.5.0 and higher
    Hopefully the new version of the plugin will be released pretty soon
    thinkerou
    @thinkerou
    Hi, I have one java project(name: X) which uses one proto jar dependency package, and the project X have not src/main/proto directory or have any proto file on src/main/proto directory. When I compile the project X which not generate target/protoc-dependencies, but I hope it have, because I want to use the whole files on target/protoc-dependencies directory to generate descriptor set. How shold I do? thanks!
    Sergei Ivanov
    @sergei-ivanov
    Hi,
    I assume that you do not have any control over the dependency jar? Or do you?
    thinkerou
    @thinkerou
    Usually, proto files as jar package are depended by other java project. I only read the proto files on the dependency proto jar. (sorry for my english)
    Sergei Ivanov
    @sergei-ivanov
    No worries, I think I understand your situation. I don’t think there’s a way for the maven plugin to generate anything if it has no .proto files in the current project. Ideally the project that contains .proto files would also generate java classes and protobuf descriptor(s) and distribute them as artifacts. But there are ways to work around that if you have no control over the dependency project.
    thinkerou
    @thinkerou
    thanks, I understand your mean. can plugin add one optional param, like createTemporaryProtoFileDirectory? I really need to use/read the dependecny proto jar. As the above said, when my project have proto file/directory, but I want to check/read proto definition which depended the current project.
    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