[MSHARED-687] Programmatic read-only access to Color API

[jira-importer]

Guillaume Boué opened MSHARED-687 and commented

We should provide a way to access programmatically the Color API, without being JAnsi specific. Read-only should suffice for now, as the styles can be changed through system properties. This would allow tools, like the Help Plugin, to interact with it without depending on the implementation.

• Refactor JAnsi specific code currently in Style into AnsiMessageBuilder.
• Make Style part of public API, and add getters boolean isBold(), boolean isBright(), String getColor(), boolean isBgBright() and String getBgColor().
• Document Style.toString() to return a comma-separated list of the style components (e.g. bold,red).
• Add a public List<String> getAvailableColorNames() method to MessageUtils. Today, it would return the list of color names in the enum Ansi.Color if JAnsi is present, otherwise an empty list.

With those changes, a consumer could for example do:

MessageUtils.buffer().success( Style.SUCCESS.toString() )

in order to print the String representation of success with its own style, while not depending on JAnsi.

---

Affects: maven-shared-utils-3.2.1

Issue Links:

• MPH-122 add help:color-style goal to describe styles color
  ("is required by")

[jira-importer]

Robert Scholte commented

I recognize the question, but I still don't understand why is would help? What does it mean what th bg color is? Or if it is bold? As if you want to make a decision based on these values.

[jira-importer]

Hervé Boutemy commented

what is the issue with a dependency on JAnsi?

[jira-importer]

Guillaume Boué commented

Robert Scholte Hervé Boutemy So the changes here are two fold: 1. have access to the current color settings and 2. have access to a list of available color names.

For 1. This can be done by making Style public, and allowing tools like the Help plugin to leverage toString() and actually print what a style is, e.g. bold,cyan. It would show clearly to users what the settings currently are, for each style, with no ambiguity (that I guess you might have by just outputting a sample message with the style).

While this doesn't strictly require factoring out the JAnsi specific code inside it, I think it'd be nice to do to avoid potential exceptions at runtime, because JAnsi dependency is (rightfully) optional in Shared Utils. Furthermore, IMO having JAnsi code inside JAnsi named classes would convey the intent better. The Style enum sounds generic and so you would expect it to be generic also, unlike AnsiMessageBuilder. Those getters in Style could stay internal, they don't really need to be exposed as they are only used by an internal class. MessageBuilder and LoggerLevelRenderer implementations need to know if something is in bold, since it alters their output. Of course today there is only the JAnsi implementation that uses it, but I suppose it could evolve... (ok maybe not... but the previous points remain).

For 2., it goes hand in hand with 1. Once you get to read what the current settings are, you wonder what are the possible values you could change it with. At best, it would avoid looking through the right version of the JAnsi docs.

What do you think? Should we support those needs, or maybe in a different manner? (thinking about it, I probably should have written 2 more specific JIRAs).

[jira-importer]

Hervé Boutemy commented

IMHO, refactoring is not necessary (and I fear it would make code complex): if color is not enabled, reading their definition does not have any meaning.

Please make a test in a branch: IMHO, it will be easier than long discussions