oscerd commented on PR #12474: URL: https://github.com/apache/camel/pull/12474#issuecomment-1864323939
> 1. It would be great to have jbang with a plugin for different command sets, as we end up with a big pile of dependencies and many commands that will get us in trouble in the future. Good to hear you do some experiment with this. Its not only the CK stuff that we can separate. It would also be for example the generator command, sbom, jolokia, hawtio etc > 2. clever way to use k as sub command to separate this clearly > 3. the get command has been called get for all its life in camel-k, and we use same name in camel-jbang, so I think its not a good idea to rename it to list (old habbits die hard) > 4. docs, the jbang docs is a very long page, it needs to be broken up into sub pages, so a good start is to have the CK in its own sub page. And then we can use that as starting point to break up the existing big page also. > 5. can the tests run in isolation or do they need a running k8s cluster. Just want to sure that we can build everyhing nicely without causing test failures due to k8s stuff as core project dont have any of that. > 6. mind that jbang is for developers and not sys admins, or ops guys. I think the kubectl, oc and kamel go cli would be needed for those guys - I cant see them want to install java jbang to run a shell command. > 7. the dependency on the camel-k fabric8 client to have those CRDs - is there in the future a better way, as its not good that the core project has a dependency on a Camel K release. Can it be the fabric8-client release instead. For the last question, the point 7, they moved back to camel-k the crd responsibility, so now we are releasing the CRDs as part of our release projects. Fabric8 Kubernetes Client started to have too much stuff to maintain. -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
