[
https://issues.apache.org/jira/browse/MSHARED-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377734#comment-16377734
]
Guillaume Boué commented on MSHARED-687:
----------------------------------------
[~rfscholte] [~hboutemy] 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).
> Programmatic read-only access to Color API
> ------------------------------------------
>
> Key: MSHARED-687
> URL: https://issues.apache.org/jira/browse/MSHARED-687
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
> Affects Versions: maven-shared-utils-3.2.1
> Reporter: Guillaume Boué
> Assignee: Guillaume Boué
> Priority: Minor
>
> 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:
> {code:java}
> MessageUtils.buffer().success( Style.SUCCESS.toString() )
> {code}
> in order to print the String representation of success with its own style,
> while not depending on JAnsi.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
