Build tool's plugin options

[andreaTP]

There are several reasoning to be done around "how we expect" users to use Kiota in their projects, among others:

• generate sources and commit the generated result
• have some sort of script to automate the code generation

Personally, I do like the approach that considers a codegen tool 100% idempotent and the generated code should be reproducible and not committed in the versioning system (i.e. regenerated all the time, build tools are good at caching the results on dev machines).

Following this(opinionated) philosophy I started automating the code generation wrapping the kiota CLI in a Maven plugin:
https://github.com/andreaTP/kiota-utils/blob/main/plugin/src/main/java/io/apicurio/kiota/KiotaMojo.java

Here I'm asking if you have already considered this aspect and what your take on the subject is.
More specifically, would you accept Maven/Gradle plugins in this repo or you prefer them to be third-party?

[baywet]

Hi @andreaTP
Thanks for sharing this idea.
This is something we've considered on our roadmap with no hard plans at the moment.
There are multiple experiences we've identified could be integrating with kiota, maven/gradle was not on the following list:

• internal and external tooling/products at Microsoft (this part is under NDA, I'd be happy to share more on a call but can't share things publicly here at the moment)
• visual studio (full version)
• visual studio code (via an extension)
• https://app.kiota.dev (experimental as this point, but fully runs in the browser)
• npm/tsc/webpack

A maven/gradle integration sounds like a great idea!
From glancing at the code, I wasn't able to tell how this would be configured in the target projects, especially in the context of generating against multiple APIs in the same project?

As per hosting and publishing it from here, let me share that with my PM and architect and get back to you.

[andreaTP]

I wasn't able to tell how this would be configured in the target projects, especially in the context of generating against multiple APIs in the same project?

An example project is in the integration test: https://github.com/andreaTP/kiota-utils/tree/main/plugin-it/src/it/basic-codegen-test
and this is the relevant configuration: https://github.com/andreaTP/kiota-utils/blob/1a7dcecd92ce8794fe479e9c37c71d5733a39ff6/plugin-it/src/it/basic-codegen-test/pom.xml#L60-L72

The target API is only one at the moment but is trivial to change it to be an Array.

As per hosting and publishing it from here, let me share that with my PM and architect and get back to you.

Thanks a ton! But, please, consider that depending on the result of #121 it might become more appealing to me to keep more control over the build tool extension.

[baywet]

Noted.

As per the configuration, yes I think we should design it in such a way that it supports multiple APIs. Or even multiple times the same API but with different filters. That's how we demo kiota and we believe it could change the API consumption paradigm.

[Sineaggi]

Could it make sense to add support for kiota-java to https://github.com/OpenAPITools/openapi-generator to, considering it already has maven/gradle plugins available?
Not sure how shareable templates are between kiota and the upstream openapi generator but potentially having templates available in both would be too much of a maintenance burden.

[andreaTP]

Could it make sense to add support for kiota-java to https://github.com/OpenAPITools/openapi-generator to, considering it already has maven/gradle plugins available?

There is no possible reuse across the two projects as the technological stack and the integration with Java projects are extremely different.

Though there is Ia Maven plugin and a Quarkus extension.