Hi Maxim, I will take a look too.
Regards,
Dmitry
On Tue, 13 May 2025 at 08:59, Štefan Miklošovič
wrote:
> Hi Maxim,
>
> I took yet another look after my initial review some time ago and I still
> do not see any issues with it.
>
> I appreciate that by default it behaves exactly the same way as
Hi Maxim,
I took yet another look after my initial review some time ago and I still
do not see any issues with it.
I appreciate that by default it behaves exactly the same way as before and
one has to just flip a switch (env property / system property) to start to
use another layout.
Arguments /
Hello everyone,
The commands have been migrated to picocli and are ready for review,
and we need a second committer to review them.
Would anyone be able to help?
Key points:
- All the commands are backwards-compatible with everything we have in
the trunk now (including the accord commands);
- The
> If you have downstream operations frequently parsing unstructured CLI output
> using sed or awk and the output has no defined contract (ideally openAPI)
> then this seems backwards to me and is going to be a constant source of
> breakage for users and friction when evolving our product.
Strong
I don’t usually chime in but I’m a +1 on PicoCLI. I think it’s a great project
and the autocompletion features are a game changer for people like me who
prefer the CLI and use many CLI tools infrequently. The coloured output is…
nice, I guess.
Whatever the decision, I think at a strategic level
On Tue, Jul 16, 2024 at 8:48 AM Jeff Jirsa wrote:
> if it’s unmaintained, let’s remove it before we’re doing it on fire.
>
+1
Fire drills are never pleasant.
CLI parsing isn't a huge area of personal interest to me. However, it
presents a non-trivial attack surface as input processing is a rip
> if someone proposed adding this library right now, we’d all say no because
> it’s unmaintained.
Interesting. This perspective resonates with me, but it also raises the
immediate next thought of "we should make it a point to proactively move off
unmaintained dependencies or take them in-tree".
> On 17. Jul 2024, at 01:28, David Capwell wrote:
>
> We also must weigh the risk of stability… Changing something for the sake of
> changing it may get past all our CI then could break a user as they used
> something we were not aware was being done (return codes, stdout/stderr,
> etc.); re
My CRA arguments basically revolve around the "Open Source Steward" from
the CRA. As far as I recall, for open source software to be used in
commercial projects it must be maintained by a steward. The definition of
steward is being discussed but foundations generally meet the requirement,
project
This particular library doesn't really present transitive dependency issues. We
already manually specify the version of the two dependencies that look like
the runtime dependencies.
On Tue, Jul 16, 2024, at 11:39 AM, Jeff Jirsa wrote:
> (Answering this as a cassandra person, don’t confuse this
I am not for or against replacing…
> I'm talkingabout CEP-38 [1], where I want to reuse the NodeTool commands and
> execute them via CQL
> 1. So the first requirement that airline doesn't fulfil is to allow us
> to stay aside from all API-specific options of the commands and only
> use them whe
With concerns around licensing all but resolved, I'd support Pico as our
airline replacement. It looks like it would entail the least risky
migration, is being actively maintained, will make the development of a
number of planned enhancements easier, etc.
On Tue, Jul 16, 2024 at 10:40 AM Jeff Jirs
(Answering this as a cassandra person, don’t confuse this reply as
board/foundation guidance)
The legal landscape is rapidly evolving with the CRA. The answer may change in
the future, but I think “we have a dependency we ship that’s user-accessible
and known to be abandoned” is an unhappy stat
Hi,
I am pretty torn down the middle on this one. Unmaintained bad, but also
Aleksey is right. If there are few/no dependencies in airline then it could be
"done" given the narrow scope of what it does.
It seems to depend on Guava, javax.inject, and findbugs. Seems like we can
probably update
Aleksey,
I wouldn't think of the NodeTool commands and the airline library it
now uses as just the cli commands (other tools are less interesting),
in a broader sense these are commands to manage a node. I'm talking
about CEP-38 [1], where I want to reuse the NodeTool commands and
execute them via
Well, we might probably stick to that, sure. If nobody objects that there
is a big fat warning about airline being deprecated and it actually
actively promotes picocli or airline 2 as its replacement in its readme.
https://github.com/airlift/airline
I get that the motivation to not change it (pro
Are there outstanding bugs in airline though, and any that affect Cassandra
specifically?
There is software that requires ongoing maintenance and these is software that
really doesn’t. These are simple libraries, doing one isolated thing, that
don’t need to change once they work - they are *don
I do not think it is completely fair to say that it is maintained by a
single individual. Looking into the commit history, the author of Picocli
is accepting patches from other contributors as well. Also, I think this
library is so broadly used that it is not going anywhere even if the
original aut
There are several reasons to consider updating, foremost in my mind is the
changes coming as part of CRA in Europe. IANAL, but I don't think that
non-maintained code will meet the CRA requirements, nor will code
maintained by a single individual.
Our best approach may be to try to get picocli me
Hi Maxim,
I think I’m not fully sold on the need to do anything at all here. The library
may no longer be maintained, but so what if it isn’t, really?
Parsing command line arguments is a pretty well defined problem, it’s not the
kind of code that rots and needs to be updated to stay operational
Hi Maxim, thank you for letting me know of this discussion.
Hello everyone,
I developed and maintain picocli; let me try to address the concerns raised
below.
For background, I am on the PMC for Apache Logging Services (mostly involved
with Log4j), and on the PMC for Apache Groovy.
My invol
Hello everyone,
I want to continue the discussion that was originally started here
[2], however, it's better to move it to a new thread with an
appropriate title, so that everyone is aware of the replacement
library we're trying to agree on.
The question is:
Does everyone agree with using Picocl
22 matches
Mail list logo
