+1, think it makes sense to widen the community/ecosystem to JVM languages (which actually use java libs a lot) with their "idoms" and types support. I also think it applies to Java BTW we should support in version >= 1.5 with annotation support which is used in 90% of cli libs today and enables more maintainable apps, code is not crazy for that too to have something usable ( https://github.com/apache/geronimo-batchee/blob/master/tools/cli/src/main/java/org/apache/batchee/cli/BatchEECLI.java#L228 ).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le dim. 20 sept. 2020 à 21:56, Oliver Heger <oliver.he...@oliver-heger.de> a écrit : > Hi Gilles, > > Am 20.09.20 um 19:44 schrieb Gilles Sadowski: > > Hello. > > > > 2020-09-17 21:47 UTC+02:00, Oliver Heger <oliver.he...@oliver-heger.de>: > >> Hi all, > >> > >> once we had a discussion (it must be one or two years ago) whether > >> Commons could support components in other (JVM) languages, too. IIRC, > >> there were no strong objections, but there has never been a follow up. > >> > >> For a project in Scala, I needed some limited functionality to process > >> command line parameters. I came up with a functional solution that > >> seemed to be pretty flexible. So I extracted the code into a separate > >> repository [1] and enhanced it. > >> > >> It is now in a shape that it supports a lot of the features typical to a > >> CLI library. The functional programming (FP) approach is probably > >> somewhat special: you define extractors using a DSL, which are actually > >> monads and thus can be nicely transformed and composed to more complex > >> structures. The end product is a configuration object representing all > >> the parameters passed to the application in a type-safe manner. The > >> repository contains a README describing the high-level concepts and a > >> tutorial [2] with a comprehensive description of all the features > >> available. > > > > How does it compare with e.g. > > https://github.com/remkop/picocli > > ? > > The philosophy is a bit different and more targeted to Scala, which > traditionally emphasizes a more functional approach. So no annotations > are used to declare targets for parameter injection, but you call a > function and get a data object back. > > Currently, not all the functionality of picocli is available, but the > footprint is smaller. > > Whether another CLI library is needed is a valid question, but I cannot > answer this. > > > > >> So I would like to ask again the question whether Commons could have > >> components in other programming languages, and more specifically, > >> whether this CLI for Scala library could be a candidate. > > > > Given the current drift towards GitHub-centered development, > > what do you expect from bringing the code here? > Frankly, more popularity. It is pretty unlikely that a repository on > Github with a single contributor will be successful. > > Thanks, > Oliver > > > > >> Notes: > >> - Except for the domain, there is no relation to the original [CLI]; the > >> concepts are completely different. > >> - The Scala CLI has been written in and for Scala; so the API can > >> probably not be used from Java directly. > >> - As special Scala language features are used, it won't be trivial to > >> port this code to Java; but maybe some of the ideas could be > >> incorporated into [CLI]? > > > > IIRC, last time significant improvements were evoked for [CLI] > > someone mentioned "picocli"... > > > > Regards, > > Gilles > > > >> > >> Thanks > >> Oliver > >> > >> [1] https://github.com/oheger/scli > >> [2] https://github.com/oheger/scli/blob/master/Tutorial.adoc > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
