Open knoguchi opened 7 years ago
I'll have to think about this a bit. But let's start with easy answers....
First of all, yes, allowing use of descriptor files sounds like a good addition, so +1 for that. I like the idea a lot, since as you say, dealing with multiple complex proto files gets tricky.
As to adding new dependencies: I am bit on the fence on that one -- I prefer minimizing dependencies. But there is no strict limit on what can be added.
So perhaps the best way would be to first start with (3), as I would be happy to add extension points first, to make this possible. And then if and when things work nicely, see if some or all of functionality could be added here.
Or maybe it could be an extension module as sub-project here -- that might be the best way? That is, another maven sub-module (jackson-module-protobuf-schema
or something), which would be built and released along with format module, but optional to use.
Maybe it'd be good if you just do simple PR first, adding extension points you would need, and we can go from there?
I totally understand your thoughts. We are on the same page. There is one thing I would like to try before making invasive changes. The .desc file itself is a PB defined by this proto. It means we should be able to load the .desc files out of the box without protobuf-java
. The other dependency, protobuf-dynamic
, is just a "nice to have" thin wrapper. No extra jars needed if this idea works.
Excellent! I like the idea even more.
I would like to create ProtobufSchema objects from the descriptor files instead of proto files.
protoc -o output.desc
can generate the descriptor fileoutput.desc
by compiling multiple proto files. It's often easier to use the descriptor file than dealing with multiple .proto files. At my work we have fairly complex proto files.I actually have an experimental implementation. I used Google's official protobuf-java and protobuf-dynamic to read the descriptor file.
Questions
thanks.