Questions and observations on initial commit

[adam-sandor]

• Awesome that this is kicking off!
• Use of picocli looks great, very nice syntax for defining commands + Quarkus integration
• Why is the submodule called jops and jops-cli if the project is called josdk-cli?
• Why is Spring Core being used? Just for some helper classes? In that case I think we shouldn't as it implies that this is a Spring project.
• Why do we need the quarkus-extension-deployment module?
• Why is the jboss Logger being used instead of slf4j?

[s-soroosh]

Why is the submodule called jops and jops-cli if the project is called josdk-cli?
I'm still not sure which name is more catchy to be used for this project, I found jops nice and set the module name to it as suggestion. once we agree on the name we can justify the project and module names.

Why is Spring Core being used? Just for some helper classes? In that case I think we shouldn't as it implies that this is a Spring project.

Yes it's already used in build time to index the resources which are needed in runtime. It can be replaced by something else but was the most convenient to do it in first iteration.

Why do we need the quarkus-extension-deployment module?

It's not possible to get the template resources out of the native-image, this is a quarkus extension to index those resources in build, picked up by cli in runtime.

Why is the jboss Logger being used instead of slf4j?

This is the default logger of the Quarkus, anything other than that would also need a jboss logger adapter, i.e. bigger binary size

[adam-sandor]

Got it @psycho-ir ! Thanks for explaining.

I like how jops sounds, but it feels misleading... sounds like some operations tooling. But let's see what others think about that.

Also about Spring I agree it's fine to have it for the first iteration, let's see if we can get rid of it later.

About the quarkus-extension-deployment module I'm wondering if we could have it all in a single one. For the CLI we don't have to make Quarkus optional. But maybe there are other reasons to make it into a separate module.

[csviri]

Why do we even use quarkus for a CLI? IMHO it just brings unnecessary complexity.

[s-soroosh]

Got it @psycho-ir ! Thanks for explaining.

I like how jops sounds, but it feels misleading... sounds like some operations tooling. But let's see what others think about that.

Also about Spring I agree it's fine to have it for the first iteration, let's see if we can get rid of it later.

About the quarkus-extension-deployment module I'm wondering if we could have it all in a single one. For the CLI we don't have to make Quarkus optional. But maybe there are other reasons to make it into a separate module.

I don't think it's possible, the extension jar file should be present during the build to be picked up as one of the build steps.

[s-soroosh]

Why do we even use quarkus for a CLI? IMHO it just brings unnecessary complexity.

It eases the native binary builds, without it build the native binaries can be tricky.
What sort of complexity do you see is added by Quarkus?
If it's about the extension, we need a way to let the cli extract the resource directories, without the extension I can think of generating a file including the address of all resource files or an annotation processor that does the similar thing in build time