Future of Jenkins CLI apps: args4j vs. picocli or other CLI libs

[Oleg Nenashev]

Hi all,

I am currently working on supporting sub-commands in Jenkinsfile Runner (issue #429). Apart from JFR, the Plugin Installation Manager Tool is also a component which implements multiple commands at the moment, and hence could benefit from sub-commands that could simplify the API. There are also other projects which could use sub-commands (e.g. Custom WAR Packager, Plugin Compatibility Tester, maybe even Jenkins core).

Currently JFR, as the most of the Jenkins ecosystem, uses the args4j library created by Kohsuke: https://github.com/kohsuke/args4j . The library does the CLI management job quite well, and it is not actively developed at the moment. It does not support sub-commands, auto-completion or advanced help generation (e.g. entry ordering). All of that could be implemented or worked around, but I wonder whether it makes sense to invest much time in that when there are other libraries which support such "more advanced" functionality. It would be great to get opinions of other contributors.

There are 2 ways:

1. Keep updating the args4j library. Again, it does the job quite well and can be updated if needed. Kohsuke is still around when a release is needed. It would save time in short term, but in longer term it may create obstacles. The library development is not very active at the moment.
2. Gradually adopt another CLI library (e.g. https://github.com/remkop/picocli) in components which need advanced CLI. Contribute fixes there if needed. This way would allow to save time on implementing features, but it will likely split the tools between 2 libraries. It may complicate contributions. Also, migration to a new lib in existing components would require time investment.

I would appreciate feedback from others. In JFR I am experimenting with picocli at the moment, but I will fall back to args4j if there is a consensus that we want to focus on it.

Best regards,

Oleg

[Matt Sicker]

I'd be hugely in favor of using picocli. It's what I use in my own CLI
tools, and the original author of the library is someone I know and
have worked on OSS projects with (Log4j2 in particular) in the past.
I'm generally in favor of migrating to maintained libraries,
especially if it means maintaining less forks in the org or at least
adopting more commonly used libraries in the modern day.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9447af42-6a78-4625-a23e-f8d18c4e1890n%40googlegroups.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

[timja...@gmail.com]

+100 to moving to picocli

[Jesse Glick]

picocli seems appropriate for new development. It is integrated with
Quarkus, too. I doubt we would want to rewrite existing Jenkins
features using args4j; in particular, `CLICommand` hard-codes it (we
could not switch compatibly).

[Oleg Nenashev]

Yup, updating CLICommand in the core is not in the table. Too much effort with low benefit, CLICommand implementation in Jenkins is already a "sub-command" from the user and developer standpoint.

When I mentioned Jenkins core, I rather meant the default "java -jar jenkins.war" entry point, and a similar one for remoting. That could be updated, and for remoting it could actually help to improve UX. But, still, not very high on the priority list.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/jTkOpdZ7z1s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0%2BvyvbovgW4oUESjNMhpsDwoKQ8cy%3D9cYU82nAVOGhdw%40mail.gmail.com.

[Manuel Ramón León Jiménez]

Hi.

Use existing, best maintained, more-future-ready solutions as much as possible. Avoid doing business that it's not our business.

Just take into account the status of every possibility to choose the best if possible. Status ~ security vulnerabilities, regularly maintained, current users, ...

+1000000

Thank you.

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBSx4N2%3Dw36qZvLaf5Y0Fkd%3D2Go0688bpC5cW0Dpxs0ag%40mail.gmail.com.

[Oleg Nenashev]

Thanks to everyone for the feedback!  I have started migrating Jenkinsfile Runner. Just in case you are curious, this is a simple pull request: https://github.com/jenkinsci/jenkinsfile-runner/pull/432 . I also have a working PoC for sub-commands, but I will deliver it separately due to a significant refactoring needed in the existing codebase for splitting the code to subcommands.

BR, Oleg