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

[petermetz]

Description

As a developer I want to not be forced to use the NodeJS/Javascript API client if my primary programming language is something else so that I can achieve high productivity through Cactus no matter the language I'm using.

• This is different from a similar looking issue which discusses the possibility of writing plugins in different languages as well.
• We do not need write much Go/Java code because 99% of it is auto-generated. See the Acceptance criteria 4)

Here is a complete list of programming languages that are supported by the OpenAPI generator (which we can take full advantage of since we are using the OpenAPI specs)
https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages

Acceptance Criteria

1. Clients for Java and Go are generated as part of the full build
2. Dev builds only build the Typescript API client to remain as fast as possible
3. Publishing of the Java and Go API clients is included in the release process => if I run the release scripts the full build runs and the Java, Go clients are published/made available for public consumption the same way we do with the Typescript API client (it gets published to npm)
4. Client side routing is supported by the Go/Java API clients as well.

cc: @takeutak @sfuji822 @jonathan-m-hamilton

[petermetz]

This blew up in complexity because the oneOf allOf keywords are not universally supported among the different OpenAPI generators the way they are for the typescript-axios generator so it's not immediately obvious how to migrate away from these unsupported keywords. The other option is to wait for them to add support (or help them implement it) so that we can just go back to a much lower complexity in the scope of this issue once those generators "just work" out of the box.

[jagpreetsinghsasan]

For the Go artifacts, publishing the api-client code (as a commit to cacti github code) itself will act as the artifact, right?
Then we can import it something like
import cactus-cmd-api-server "github.com/hyperledger/cacti/packages/cactus-cmd-api-server/src/main/go/generated/openapi/go-client"
@petermetz is this fine?

[jagpreetsinghsasan]

The kotlin jar generation is broken, mostly due to openapi-generator upgrade, will fix those alongwith this issue.

[petermetz]

For the Go artifacts, publishing the api-client code (as a commit to cacti github code) itself will act as the artifact, right? Then we can import it something like import cactus-cmd-api-server "github.com/hyperledger/cacti/packages/cactus-cmd-api-server/src/main/go/generated/openapi/go-client" @petermetz is this fine?

@jagpreetsinghsasan Yes, works fine for me. Please open a follow-up issue there to mimic how it is being done for the weaver components (@sandeepnRES wrote some scripts or GH actions to do tag based releases IIRC)

[jagpreetsinghsasan]

One of the issues I faced during generating java artifacts was that in cactus-core-api openapi specs, we have a field within JWSRecipient termed protected which matches with the Java protected keyword, thus the generated code cannot produce the respective client JAR
(I will create an issue to address the same, mentioning it for future reference)

[jagpreetsinghsasan]

Openapi specs

Generated code (throwing errors)

[jagpreetsinghsasan]

JAR parsing for cactus-plugin-htlc-eth-besu, cactuls-plugin-htlc-eth-besu-erc20, connector-besu, connector-ethereum, connector-quorum, connector-xdai fails due to invalid Java code being generated

Other devs are also facing the same issue: OpenAPITools/openapi-generator#12556 (comment)

[jagpreetsinghsasan]

connector-iroha , connector-iroha2 faces yet another bug related to openapi codegen (<, > signs arent rendered correctly)
OpenAPITools/openapi-generator#11601

[jagpreetsinghsasan]

As per the conversation here, dropping the java clients from the issue (as the same is already achieved using Kotlin)

[petermetz]

As per the conversation here, dropping the java clients from the issue (as the same is already achieved using Kotlin)

@jagpreetsinghsasan Thank you!