-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ELY-2082] Optimise Tool Help Text #1713
Conversation
@@ -607,4 +607,9 @@ public interface ElytronToolMessages extends BasicLogger { | |||
@Message(id = 35, value = "Only one of '%s' and '%s' can be specified at the same time") | |||
IllegalArgumentException mutuallyExclusiveOptions(String first, String second); | |||
|
|||
@Message(id = NONE, value = "To get list of options for specific command, please specify the command by using ./elytron-tool.sh [command] --help") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor, this should be placed before the Numeric Errors
comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/get list of options for specific command/get a list of options for a specific command
@petrberan This looks good! Later I will try on windows also just to make sure it prints out well. With this formating I noticed that we should standardize our output when defining commands. Currently we use single/double quotes randomly and FileSystemRealm should be filesystem-realm:
|
Thank you @Skyllarr for the Windows testing. As for the single/double quotes, in the recent forced commit I unified the quotes to be double ones, as I believe all commands are represented by strings rather than characters. By looking at those messages I believe we could also go and polish the rest as well.
|
@petrberan Thank you for unifying the quotes! As for windows testing, when running the tool from the windows command line I get the following:
so the ANSI escape codes do not work on windows it seems |
@petrberan I did not find yet, but there could be some library/specific codes that can be used to have working colors in both environments. Or in the worst case we can do without colors |
Thank you @Skyllarr for looking into this. I was afraid that it wouldn't work on Windows, apparently it used to work before Win 10 or something like that. Regardless, there are multiple way how to tackle this problem:
Personally, I'd go for option 2) since I believe CLI colors on Windows work fine. If for some reason it would not be possible to use Aesh, I'd find a different library (3), something lightweight preferably. And if all that fails, then we'd have to go without fancy colors (1). |
@petrberan Thank you for explanation! Yes I agree with your idea of trying what wilfly-core uses first and then see if anything else needs to be done |
@Skyllarr I managed to use the Aesh library from WFCORE, just two lines here so the Apache CLI functionality is intact. The color works just fine on my machine, could you please try it on Windows as well? You need to add |
stringBuilder.append(System.lineSeparator()); | ||
} | ||
|
||
else{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor, this could be formatted better
@petrberan I really apologize for late review. I tried on windows and colors are working great! There is 1 issue I noticed, see the included picture. Basically when the terminal is narrow, there are some misaligned new lines in the options sections. This is happening on linux as well. Can you tell where the problem could be? The picture is result of UPDATE: I tried |
This is a great improvement! This now needs a second approval, but after that we should not forget to create the related WFCORE issue |
Thank you for looking into this @Skyllarr . As for the formatting, this is caused by the Apache CLI since I didn't touch the Options section at all. I remember I was thinking about not using the CLI but doing some custom formatting and I can't remember why I chose this option, if for the simple "5 lines of code vs 60" or any other reason. I could try custom formatting again if you'd like to. As for the WFCORE, I'll create a new issue that will be merged once this one is in Elytron |
@Skyllarr Did some refactoring, the code format should be slightly better. I also created an issue for the WFCORE module changes - wildfly/wildfly-core#5257 . I presume the WFCORE PR will be merged after this one, or rather when the new Elytron module will contain this PR |
Hi @fjuma can I ask for review please? |
Tested it out, looks good! |
@fjuma I just tested as well and looks good! |
@fjuma Can I ask for a review please? |
@petrberan Would you be able to update this so it's against the 2.x branch instead of the 1.x branch? Thanks and apologies for the delayed review. |
Hi @fjuma , managed to finally rebase it to 2.x |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@petrberan Apologies for the delayed review! This is looking great! I've added a few very small comments to address in the new year and then this one should be good to go. Thanks very much for working on this, it looks very nice!
@@ -607,4 +607,9 @@ public interface ElytronToolMessages extends BasicLogger { | |||
@Message(id = 35, value = "Only one of '%s' and '%s' can be specified at the same time") | |||
IllegalArgumentException mutuallyExclusiveOptions(String first, String second); | |||
|
|||
@Message(id = NONE, value = "To get list of options for specific command, please specify the command by using ./elytron-tool.sh [command] --help") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/get list of options for specific command/get a list of options for a specific command
pom.xml
Outdated
@@ -98,6 +98,7 @@ | |||
<version.io.rest-assured>4.3.3</version.io.rest-assured> | |||
<version.net.sourceforge.htmlunit.htmlunit>2.40.0</version.net.sourceforge.htmlunit.htmlunit> | |||
<version.org.apache.santuario>2.3.0</version.org.apache.santuario> | |||
<version.org.aesh>2.4</version.org.aesh> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should update this to the latest version.
@@ -0,0 +1,116 @@ | |||
/* | |||
* JBoss, Home of Professional Open Source. | |||
* Copyright 2022 Red Hat, Inc., and individual contributors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor, but we can update the year in the new files (sorry for the delayed review!).
@@ -105,25 +105,25 @@ public interface ElytronToolMessages extends BasicLogger { | |||
"Provider must be installed through java.security file or through service loader from properly packaged jar file on classpath.") | |||
String cmdLineCustomCredentialStoreProviderDesc(); | |||
|
|||
@Message(id = NONE, value = "Create credential store (Action)") | |||
@Message(id = NONE, value = "* Create credential store") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering if we should have the * at the end instead of the beginning just to be consistent with the way Action was displayed before. Maybe it stands more at the beginning though?
@Skyllarr @petrberan What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi there @fjuma , thank you for your review, I'll try to get those resolved asap
Just wanted to point here the UX solution behind the *. The problem with (Action) being at the end is that since all those lines are not the same length, it's very hard for us to find out which command is action and which not, as it requires to read every single line up until the very end of said line. Us humans being very lazy, we don't generally do that :) For that reason, I'd put it in the beginning of the line.
However, since (Action) is just another word, it doesn't stand out enough to be noticed at first. By replacing (Action) with * it's something extra that moves the entire line a little bit, showing exactly which command is action and which not.
In the end, it's all about what you want exactly. If you want user to know which command is action and which not, putting * in the beginning is better. If you prefer user to read the command easily and don't really care about them knowing whether it's an action or not, it could stay in the back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @petrberan, thanks for the explanation! Putting the * at the beginning makes sense then.
Hi @fjuma , all requested changes should be resolved, the new command's formatting is set to the new style as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much for the updates, @petrberan! This looks great!
@Skyllarr Since you last reviewed this one a little while ago, please take a quick look at the updates when you get a chance and then this one should be good to go. Thanks! |
Hi @petrberan , I just did another sanity check on windows, but the colors when I run ←[1;96;109mDESCRIPTION←[0m I am not sure why it was not this way last time I tested, but I suspect I made a mistake by trying it out in the window's If it won't be trivial to make colors work for all OSs, it is okay IMO to not use colors in this PR, the formatting is a great improvement on its own |
Hi @petrberan is it possible to follow up on the last suggestions from @Skyllarr so we can see if we can get this through? |
Hi @darranl , it's on my todo list but I've been caught on another issues, still planning to look into it. The last comment was actually resolved by adding the aesh module into WFCORE (as it should be), but the colors don't work on some of the Windows consoles, where WFLY colors work properly. Since both projects use the aesh library, that should be bug and I'll look more into it |
Managed to find the culprit. Problem was that even Aesh created the title strings properly, they displayed incorrectly on old Windows terminal because they wasn't printed by Aesh, but by the system itself. Added missing TerminalConnection and now Aesh handles printing those titles itself, working properly. Works fine on Linux and Windows VM, can you please have a look as well? @Skyllarr Please make sure that WFCORE contains the Aesh dependency in the module.xml as well |
Hi @Skyllarr , any news? |
@ivassile Do you have access to a Windows VM or machine by any chance to try this out? |
I don't have Windows VM, but will setup and test it tomorrow. |
That would be great, thanks Ilia! |
@fjuma I tested the changes on Windows 10 and the help command displays fine. |
@petrberan Can you please rebase? Thanks! |
Rebased @ivassile |
@fjuma This PR can be merged now. |
I have just put the WildFly Core PR on CI to double check, if that passes I will merge both. IMO we don't actually need to merge together, the proposed change to WildFly Core is safe to merge on it's own. Thank you @petrberan |
https://issues.redhat.com/browse/ELY-2082