Skip to content
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

MNG-6220 add color CLI option #114

Closed
wants to merge 4 commits into from
Closed

Conversation

mryan43
Copy link

@mryan43 mryan43 commented Apr 18, 2017

@michael-o
Copy link
Member

I will comment shortly.

@michael-o
Copy link
Member

They are several issues. People are used to GNU and BSD tools like grep. They use values never, always, auto. Having said that I do think we need to do this exactly the same way: grep.c. Option always requires special attention due to isatty in combination with less(1).

@michael-o
Copy link
Member

Two issues:

  1. Unfortunately, Commons CLI does not offer valid values. If it would, it would fail if the option value is wrong. I would do so too.
  2. You blindly return from always, but still forget that Jansi will ignore that because isatty returns false as soon as stdout is passed via pipe.

@mryan43
Copy link
Author

mryan43 commented Apr 18, 2017

Good idea to align the name of choices with grep, I just changed it.

About "isatty", do you think we should set the jansi.force system property when --color is set to "always" ? https://github.com/fusesource/jansi/blob/2616142fda4425d779ac94a3d9bfa76412021b23/jansi/src/main/java/org/fusesource/jansi/AnsiConsole.java

@michael-o
Copy link
Member

I think yes, grep doesn't do different. Please try the patch thoroughly!

@mryan43
Copy link
Author

mryan43 commented Apr 18, 2017

I will test with less and jenkins and comment again with results.

@mryan43
Copy link
Author

mryan43 commented Apr 18, 2017

Unfortunately, the system property is read only once in a static init block in the JansiConsole class before the cli main method is invoked, so my change doesn't work.

We have a kind of chicken and egg situation and we need to decide if we prefer

a) not setting up Jansi until arguments/config have been parsed and validated (and call MessageUtils.systemInstall(); later in the loggin() method)

b) forcing jansi until arguments and config have been parsed (by adding System.setProperty( "jansi.force", "true" ); before MessageUtils.systemInstall(); in MavenCli#main and then eventually disable it later in the loggin() method

What do you think ?

…arsing color option and apply auto-detection when --color=auto
@mryan43
Copy link
Author

mryan43 commented Apr 20, 2017

I applied solution B.

I have added an auto-detection method in MessageUtils in my fork of maven-shared-utils (https://github.com/mryan43/maven-shared) based on the corresponding code in jansi.

Unfortunately, upgrading to 3.2.0-SNAPSHOT from maven breaks compilation because of changes done for MSHARED-587 but I'm affraid fixing them would be out of scope of this PR.

@mryan43
Copy link
Author

mryan43 commented Aug 9, 2017

I feel stuck until someone with more experience of the maven code base update the version of maven-shared-utils to 3.2.1-SNAPSHOT on the default branch, anyone up to the task ?

@michael-o
Copy link
Member

I don't might to pick this up, but it won't happen before Sep for personal priorities.

@rfscholte
Copy link
Contributor

@agudian
Copy link
Member

agudian commented Aug 16, 2017

@rfscholte: looks good! 👍

@mryan43
Copy link
Author

mryan43 commented Aug 16, 2017

Great thanks @rfscholte !

@mryan43 mryan43 closed this Aug 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants