This thread is clearly mostly not about the feature branch question, but
sure...let's summarize the case for picocli (rather than airline-2,
jcommander, and commons-cli) in a fresh, specifically titled thread. Then
we can continue any library-agnostic discussion here if necessary.
On Mon, Jul 8, 2
Many of the utilities in the tools directory (BulkLoader, SSTableExpoert,
etc) already use apache.commons.cli.
On Mon, Jul 8, 2024 at 4:28 PM Dinesh Joshi wrote:
> I agree about picking libraries on their merit but a major factor for any
> open source project should consider today is the possibi
I agree about picking libraries on their merit but a major factor for any
open source project should consider today is the possibility of
unfavorable/hostile licensing changes.
On Mon, Jul 8, 2024 at 1:15 PM Jon Haddad wrote:
> Without getting into the pros and cons of both libraries, I have to
Without getting into the pros and cons of both libraries, I have to point
out there's something unsettling about making decisions about libraries we
used based on arbitrary rules an employer has put into place on its
employees. The project isn't governed by Apple, it's governed by
individual contr
I agree, having a DISCUSS thread with a specific subject line is less
likely to be overlooked.
One thing I'd like to note here is PicoCLI and Airline 2 are independent
projects that are ALv2 licensed. A subset of the Cassandra contributors may
have difficulty contributing to such projects due to p
> I don't think that a separate thread would add extra visibility
Disagree. This thread is about adding a feature branch, so many could ignore
if they don’t care. The fact you are switching the library (and which one) is
something we have to hunt for. By having a new DISCUSS thread it makes i
+1 on picocli
RE the feature branch, I would just maintain the feature branch in your own
fork to break out whatever "reviewable units" of code you want. When all
the incremental review is done (I have no problem going back and forth),
squash everything together, do whatever additional testing you
> Once you are happy with your chosen library, we need a DISCUSS thread to add
> this new library (current protocol).
Thanks, David. This is a good point, do we need a separate DISCUSS
thread or can we just use this one? I'm in favour of keeping the
discussion in one place, especially when topics
> I don't personally think there is a strong need for a feature branch. If it
> makes it easy for you, please go ahead with a feature branch.
Agree, I don’t see the reason for a feature branch… feature branch just means
the branch lives in apache domain rather than your own fork. You won’t be
Thank you all for your comments,
I want to stress, that these changes won't affect the input/output
formatting of commands, ensuring everything is the same.
We are changing the command markup library, so there are two extra
things to be checked:
- We parse CLI arguments in the same way (as the pa
I don't personally think there is a strong need for a feature branch. If it
makes it easy for you, please go ahead with a feature branch.
One thing I had raised in the past was the desire to have a flag that would
generate machine readable output for nodetool commands. If this can be done
with a m
Oh yes ... THAT thread. Everytime I want to change the output of a nodetool
command, it is a never-ending story of running in circles if we can do
that. My perception is that we are very sensitive to what it looks like and
that we are not breaking it. Addition is mostly fine but god forbid when
som
On Mon, Jul 1, 2024 at 12:30 PM Jon Haddad wrote:
>
> I also don't think keeping the output consistent needs to be a strict long
> term requirement. We *should* have either a JSON output option for every
> command, or a virtual table for structured data. I don't remember us ever
> making a pr
> I personally don't have anything against what you suggested, however I
think that this kind of work will put additional stress on us being sure
that the output of the commands will be exactly as it is now. We do have
nodetool tests which are covering the tests for the output which is very
handy i
+1 on the feature branch allowing breaking the effort into smaller chunks that
can be even worked in parallel.
> On Jul 1, 2024, at 3:13 AM, Štefan Miklošovič wrote:
>
> Hi Maxim,
>
> thank you for doing this. I think that Picocli is a great choice, comparing
> it with airline v2 which is a
Hi Maxim,
thank you for doing this. I think that Picocli is a great choice, comparing
it with airline v2 which is an attempt to resurrect the original airline,
it seems to be way more active and popular.
I personally don't have anything against what you suggested, however I
think that this kind o
Hello everyone,
The nodetool relies on the airlift/airline library to mark up the CLI
commands used to manage Cassandra, which are part of our public API.
This library is no longer maintained, so we need to update it anyway,
and the good news is that we already have several good alternatives:
air
17 matches
Mail list logo
