+100 to moving to picocli On Monday, 23 November 2020 at 21:02:06 UTC msi...@cloudbees.com wrote:
> 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. > > On Mon, Nov 23, 2020 at 2:57 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote: > > > > 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: > > > > 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. > > 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 > > > > -- > > 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 > -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/210b27b5-c6cf-489b-be1e-722bda9c0152n%40googlegroups.com.
