-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add bootjar so that codegenerator can be included as artifact #14
Conversation
This allows inclusing of pb-and-k from maven without any need of local installation
I don't really use spring (and many others don't either) and in general I'm not wanting to infect my build script with it. Assuming I understand the purpose here, why use maven to get the JAR if you need it all self-contained? If you want a self-contained release, there are release packages downloadable from the release area. Can you help me understand why you need a self-contained executable boot jar instead of the executable already provided by assemble? |
Many projects are distributed as gradle projects. The expectation is that you can compile them by typing './gradlew assembleDebug' without preinstalling anything. Having to preinstall pb-and-k breaks this expectation with this patch I can put in build.gradle .....
|
I mention in the README under "Not Yet Implemented": "Protobuf code generator in Kotlin Native for easier importing". Currently the protoc-gen-kotlin generator is only built for the JVM. As mentioned in the README, to build the protoc-gen-kotlin code generator:
That builds the artifacts that you can also download in the releases area. To have the artifacts locally, you can run Maybe if you can tell me exactly what you are trying to do I can help you find the best way. |
Yes "Protobuf code generator in Kotlin Native for easier importing" is exactly what I want. Maybe it would make sense if I prepare the PR to make "Protobuf code generator in Kotlin Native" work? |
@phcoder - Sure. The JVM one works fine btw, but a native one would be nice, but it's not a requirement to use the project in any way. I have already done most of the abstraction as common code at One of the problems you might run into is converting bytes to CodeGeneratorRequest/CodeGeneratorResponse. This is because you can't dogfood this project until #7 is complete. |
@cretz It seems thatit's possible to remove dependency on platform protobuf libraries. Trying to do it, let's see how it goes. How important is it to keep api source-compatible? I'd like to make Marshaller an abstract class with ByteArrayMarshaller available on all the platforms and then platform providing only functions to read/write from stream |
I'm implementing #7 in pure kotlin. Wait couple of days |
This allows inclusing of pb-and-k from maven without any need of local
installation