Hi,

PicoCLI porting is complete. All PRs marked for 10.x backport. All BATS tests 
pass.
Still, this is opt-in and the commons-cli is the default parser.
Since all tools landed in time for 10.2, faster than anticipated, I'm tempted at
defaulting to PicoCLI parser for 10.2, and documenting SOLR_PICOCLI=false
as an escape hatch if anyone get issues with compatibility.

If we leave commons-cli the default, only a tiny percentage will ever try it.

WDYT?

Jan


> 15. mai 2026 kl. 16:54 skrev Christos Malliaridis <[email protected]>:
> 
> Considering the migration of the Admin UI and the Kotlin-contributions in
> the last months, I believe that a Java library is the right choice here.
> The reason I am asking these questions is to see if we are able to address
> some of the more important issues, including the scripting footprint in the
> project, as these have been a problem for the past releases for me
> personally (couldn't run many scripts on Windows).
> 
> So it is not about the best solution, it is more about "what problems are
> we actually addressing" with the switch to / integration of a new library.
> 
> Happy to see PicoCLI in action. Keep up that good work. :)
> 
> On Fri, May 15, 2026 at 5:21 PM Jan Høydahl <[email protected]> wrote:
> 
>> Hi,
>> 
>> To be honest Clikt was never considered, but looking at it I would choose
>> picocli
>> again due to its zero-deps (no kotlin), annotation-based approach, ability
>> to
>> hook in the doc-generator, more usage in java-land etc.
>> 
>> We do not always need to pick THE BEST tool for everything, sometimes it
>> is ok
>> to go with something that has a high adoption and is clearly an
>> improvement IMO.
>> 
>> When it comes to shrinking the shell scripts, that is not directly enabled
>> by PicoCLI.
>> But I believe that the easier and more pleasant it is to maintail java CLI
>> tools, the
>> faster we'll be able to move more logic over.
>> 
>> Jan
>> 
>>> 15. mai 2026 kl. 13:54 skrev Christos Malliaridis <
>> [email protected]>:
>>> 
>>> Nice to see efforts towards improving the CLI.
>>> 
>>> I haven't tracked any discussions since the time I was following a
>> similar
>>> approach with Clikt and dropped it due to the lack of time. Is there
>>> somewhere a document or discussion thread that provides more information
>>> why PicoCLI is a good choice, and which of the current problems are
>>> addressed by it (besides the benefits you mentioned above)?
>>> 
>>> I would be interested to see how it compares to Clikt that I chose back
>>> then and learn from it. I also remember that the platform-specific shell
>>> scripts and the test coverage were two of the bigger issues we wanted to
>>> address. Are these addressed with PicoCLI?
>>> 
>>> Best,
>>> Christos
>>> 
>>> On Fri, May 15, 2026 at 2:24 PM Jan Høydahl <[email protected]>
>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> An effort has started to transition Solr from commons-cli to the more
>>>> capable PicoCLI (https://picocli.info).
>>>> 
>>>> Many reasons it will serve us better
>>>> * More modern annotation based approach, easier to maintain
>>>> * Built in support for sub commands
>>>> * Keep all option docs, usage docs, examples etc in code annotations ->
>> no
>>>> doc drift
>>>> * Auto generate CLI documentation for the reference guide
>>>> 
>>>> The JIRA for this effort is
>>>> https://issues.apache.org/jira/browse/SOLR-17697
>>>> 
>>>> If you want to help, there are instructions in the JIRA for how to join
>> in.
>>>> The effort is divided in many small tasks and is well suited for new
>>>> contributors.
>>>> 
>>>> Jan
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to