lburgazzoli opened a new issue, #4796: URL: https://github.com/apache/camel-k/issues/4796
### Requirement Leverage camel-ka s a lib ### Problem I'm working on an golang based operator that interact with camel-k, hence I want to leverage the camel-k APIs and the client, however, due to the changes related the #4686, things seems to be much more complicated than what it should be as: - a number of indirect dependencies are eventually conflicting with local dependencies, as example the OpenShift dependencies may be problematic, however, camel-k APIs and Client should ideally not require any OpenShift library as those are only needed by the operator - the import packages now must have the `v2` in the path, like `github.com/apache/camel-k/v2/pkg/client/camel/clientset/versioned` which is fine according to the go spec however I don't see breaking changes in the camel-k APIs ### Proposal We should revisit the way the camel-k packages are exposed for 3rd party usage. ### Open questions _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
