build(api-client): generate java, go clients

[TheJagpreet]

Commit to be reviewed

build(api-client): generate java, go clients

Primary Changes
---------------
1. Updated package.json of packages to include the new
   codegen scripts
2. Added a new workflow to create and upload the jars from
   the newly added code

Changes required to incorporate 1)
---------------------------------
3. Added replace package to assist the codegen scripts written in package.json

Fixes #393

Pull Request Requirements

• [x] Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• [x] Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• [x] Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• [x] Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• [x] Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners For rebasing and squashing, here's a must read guide for beginners.

[TheJagpreet]

@jagpreetsinghsasan Thank you for this! In general, LGTM.

Any reason why we can't use the kotlin based templates (I can imagine many, but we should documetn the decision and the reasons for it in the commit message)

P.S.: The custom-checks were broken because the package.json files became unsorted, I remedied the situation and did a force push to your branch. Please make sure not to accidentally erase those changes!

Here we are generating the java client code and their corresponding artifacts, so

1. For the java client code, we can transpile the code from kotlin to java (but then thats more like using a transpiler and not the raw openapi specs directly to generate the java code). Shall I look into generating the java code in this way then, if this reasoning is not right?
2. The failure in generating jars from generated java code (in certain plugins), also documents that, straightaway openapi specs -> java code -> jar doesnt work as intented and if a developer wants to extensively use the straightaway java codegen, then our work done around this (and figuring out what actually is wrong from openapi codegen side will be helpful while investing time and will give a right direction).

Everything seems fine after your force push, compiling correctly, so no issues there.

[petermetz]

Here we are generating the java client code and their corresponding artifacts, so

1. For the java client code, we can transpile the code from kotlin to java (but then thats more like using a transpiler and not the raw openapi specs directly to generate the java code). Shall I look into generating the java code in this way then, if this reasoning is not right?

@jagpreetsinghsasan I'd say we transpile from the JSON spec to the target language (of our choice) directly in each case (be that java or kotlin). Right now you are saying -g java in the package.json scripts and I'm suggesting to keep with the pre-existing convention [1] and say -g kotlin unless there is a good reason to not to do that.

[1] =>

[petermetz]

2. The failure in generating jars from generated java code (in certain plugins), also documents that, straightaway openapi specs -> java code -> jar doesnt work as intented and if a developer wants to extensively use the straightaway java codegen, then our work done around this (and figuring out what actually is wrong from openapi codegen side will be helpful while investing time and will give a right direction).

@jagpreetsinghsasan This works for me on the main branch, so maybe these issues are only happening for the java template and not the kotlin one?

yarn install
yarn configure
yarn codegen
cd packages/cactus-cmd-api-server/src/main/kotlin/generated/openapi/kotlin-client

$ gradle build
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

BUILD SUCCESSFUL in 21s
3 actionable tasks: 3 executed

$ gradle jar

BUILD SUCCESSFUL in 496ms
3 actionable tasks: 3 up-to-date

$ ls -alt build/libs/kotlin-client-1.0.0.jar 
-rw-r--r-- 1 peter peter 74501 Jan 31 17:33 build/libs/kotlin-client-1.0.0.jar

[TheJagpreet]

Here we are generating the java client code and their corresponding artifacts, so

1. For the java client code, we can transpile the code from kotlin to java (but then thats more like using a transpiler and not the raw openapi specs directly to generate the java code). Shall I look into generating the java code in this way then, if this reasoning is not right?

@jagpreetsinghsasan I'd say we transpile from the JSON spec to the target language (of our choice) directly in each case (be that java or kotlin). Right now you are saying -g java in the package.json scripts and I'm suggesting to keep with the pre-existing convention [1] and say -g kotlin unless there is a good reason to not to do that.

[1] =>

@petermetz I would prefer not to generate jars from kotlin (for the java code), because generating the jar artifact is sort of a confirmation that the generated code is correct. So if I generate the code for java directly from openapi, but then I generate the relevant jar using kotlin (although both the jars from java and kotlin should be the same, but their source code can be different/wrong, given what the transpile logic is specified for it), it would be not appropriate

[petermetz]

Here we are generating the java client code and their corresponding artifacts, so

1. For the java client code, we can transpile the code from kotlin to java (but then thats more like using a transpiler and not the raw openapi specs directly to generate the java code). Shall I look into generating the java code in this way then, if this reasoning is not right?

@jagpreetsinghsasan I'd say we transpile from the JSON spec to the target language (of our choice) directly in each case (be that java or kotlin). Right now you are saying -g java in the package.json scripts and I'm suggesting to keep with the pre-existing convention [1] and say -g kotlin unless there is a good reason to not to do that. [1] =>

@petermetz I would prefer not to generate jars from kotlin (for the java code), because generating the jar artifact is sort of a confirmation that the generated code is correct. So if I generate the code for java directly from openapi, but then I generate the relevant jar using kotlin (although both the jars from java and kotlin should be the same, but their source code can be different/wrong, given what the transpile logic is specified for it), it would be not appropriate

@jagpreetsingsasan Yeah my point is to do kotlin everywhere. That's why I said -g kotlin above. E.g., don't generate java code, generate kotlin code.

[TheJagpreet]

Here we are generating the java client code and their corresponding artifacts, so

1. For the java client code, we can transpile the code from kotlin to java (but then thats more like using a transpiler and not the raw openapi specs directly to generate the java code). Shall I look into generating the java code in this way then, if this reasoning is not right?

@jagpreetsinghsasan I'd say we transpile from the JSON spec to the target language (of our choice) directly in each case (be that java or kotlin). Right now you are saying -g java in the package.json scripts and I'm suggesting to keep with the pre-existing convention [1] and say -g kotlin unless there is a good reason to not to do that. [1] =>

@petermetz I would prefer not to generate jars from kotlin (for the java code), because generating the jar artifact is sort of a confirmation that the generated code is correct. So if I generate the code for java directly from openapi, but then I generate the relevant jar using kotlin (although both the jars from java and kotlin should be the same, but their source code can be different/wrong, given what the transpile logic is specified for it), it would be not appropriate

@jagpreetsingsasan Yeah my point is to do kotlin everywhere. That's why I said -g kotlin above. E.g., don't generate java code, generate kotlin code.

We are already generating kotlin code sepearetly with -g kotlin argument in the codegen scripts. So I shall I just remove the java codegen entirely?

[petermetz]

Here we are generating the java client code and their corresponding artifacts, so

1. For the java client code, we can transpile the code from kotlin to java (but then thats more like using a transpiler and not the raw openapi specs directly to generate the java code). Shall I look into generating the java code in this way then, if this reasoning is not right?

@jagpreetsinghsasan I'd say we transpile from the JSON spec to the target language (of our choice) directly in each case (be that java or kotlin). Right now you are saying -g java in the package.json scripts and I'm suggesting to keep with the pre-existing convention [1] and say -g kotlin unless there is a good reason to not to do that. [1] =>

@petermetz I would prefer not to generate jars from kotlin (for the java code), because generating the jar artifact is sort of a confirmation that the generated code is correct. So if I generate the code for java directly from openapi, but then I generate the relevant jar using kotlin (although both the jars from java and kotlin should be the same, but their source code can be different/wrong, given what the transpile logic is specified for it), it would be not appropriate

@jagpreetsingsasan Yeah my point is to do kotlin everywhere. That's why I said -g kotlin above. E.g., don't generate java code, generate kotlin code.

We are already generating kotlin code sepearetly with -g kotlin argument in the codegen scripts. So I shall I just remove the java codegen entirely?

@jagpreetsinghsasan Yeah that's what I'd do. The kotlin code can be used to produce the JVM .jar files anyway so we don't need the java generated code IMO at all. Also: Sorry for the slow response, I just saw this!

[TheJagpreet]

Closing this PR. Will create a new one