Closed Perdjesk closed 1 month ago
Hi @Perdjesk Thanks for using kiota and for bringing this up. The reason why this dependency is a "runtime" dependency is because it's added as an implementation dependency. https://github.com/microsoft/kiota-java/blob/6f9a3219a543fe30525931339e33bd8ad27ae2f3/components/serialization/json/gradle/dependencies.gradle#L10
And the reason why it's an implementation dependency is that when it wasn't, people were complaining about getting conflicts with the versions they have in their project when different.
kiota info -l java instructs people to add jakarta as a dependency to avoid missing the annotation definition.
Do you feel like we should change the configuration of this dependency?
For reference, the different configurations available for java-plugin
Thanks for your thoughtful answer.
kiota info -l java instructs people to add jakarta as a dependency to avoid missing the annotation definition.
As a new user of kiota I didn't find the kiota info
before you mentioned it. However I was following:
https://github.com/microsoft/kiota-java & https://learn.microsoft.com/en-us/openapi/kiota/quickstarts/java
and both are not yet including the part about the jakarta dependency.
people were complaining about getting conflicts with the versions they have in their project when different.
Do you have some public references of those reports. I couldn't find any at:
Maven doesn't have the feature of gradle java-library plugin to distinguish api
and implementation
while providing both during compilation.
Using Maven, any dependency that is used within the generated code by kiota must be in maven compile
scope for that generated code to compile.
I am assuming some users might encounter issues when integrating the generated code within larger projects and due to the omnipresence of the jakarta-annotations-api dependency.
kiota's current state assumes that a conflict will always or likely occur for that specific dependency, requiring users to address it within their project's POM, even if no conflict actually occurs.
For example in a smaller or new project using kiota's generated code, having jakarta-annotations-api provided through kiota transitive dependencies would be fine.
However as the generated code itself include usage of this dependency some users might prefer the explicit dependency in their POM instead of relying on transitive dependencies within their codebase (i.e called "used but undeclared" by maven-dependency-plugin:analyze).
Do you feel like we should change the configuration of this dependency?
I prefer the version that asks users to have explicitly in their POM all the dependencies used within the code generated by kiota, and avoid the generated code to rely on transitive dependencies.
Conclusion is that the three docs (i.e github README, learn.microsoft.com, kiota info
) are out of sync.
Reference for Maven's dependency mediation and scopes: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
Thanks for letting us know about the documentation gaps I'll work on pull requests to address those.
As for the reports of conflicting versions it was for JavaX at the time. https://github.com/microsoftgraph/msgraph-sdk-java/issues/705
And thank you for the additional context here we might consider changing this setting again if we get additional feedback along those lines.
The artifacts over https://oss.sonatype.org/#nexus-search;quick~kiota have the dependency with scope
runtime
. Example https://oss.sonatype.org/service/local/repositories/releases/content/com/microsoft/kiota/microsoft-kiota-serialization-json/1.1.14/microsoft-kiota-serialization-json-1.1.14.pomThe generated code includes usage of this API:
Which leads to compilation errors: