I'm thinking at the API for one week now, and I think I found a simple idea: let me 2 days (no time to work on it today) and we'll review
Regards, Hervé Le mercredi 15 juin 2016 17:37:08 Jason Dillon a écrit : > > And if folks really just want any use of green to become blue, then yes > > you can do that now and there is no reason to change anything further. > > Though I kinda doubt that is what folks want when then think about > > customization of colors. I expect folks really want more control over > > “logger-level-info” is blue or green, similar to how IDEA or Eclipse can > > let you configure colors based on context, and not simply doing color > > replacements (i.e. everything green is now blue). > > > > > > Ok. Maybe we should not export jansi to plugin classpaths' then. We may > need to provide a more sophisticated logging API supporting things like > color and bold, italic, etc. If plugin developers start using jansi to > provide ANSI escapes in log messages we cannot change anything to what > they do later. > I’d recommend the simple impl to see how the community takes to colors and > gather feedback and ideas before doing anything more. > > I do think if folks are keen to the colors that perhaps a larger change to > normalize how output is handled is probably in order, and that is why I > didn’t try to go adding ansi directly to the plugin development api yet, > but left it just in the logging system. > > I’m also not sure I’d want to expose ansi sequences directly to plugin > development, but perhaps instead using an AnsiRenderer > ( https://github.com/fusesource/jansi/blob/master/jansi/src/main/java/org/f > usesource/jansi/AnsiRenderer.java ) style abstraction over the streams. > Here I could imagine it fairly trivial to externalize the color attributes > to a mapping model. > > I also don’t think that colors should be over-used, so exposing directly as > api to all plugins could end up with pretty rainbow vomit on the console > which could potentially negate the value of having colors to help signify > bad or good things. Adding colors presently is a simple easy way at a > glance to see these. But if it was up to each plugin to color as it felt, > then the brain power needed to comprehend the output would grow > exponentially, unless there was some abstraction over “good”, “bad”, > “warning”, etc concepts. > > * * * > > In short, I would not recommend jumping directly into making ansi coloring > of output part of the api proper and exposing to the community for > extension at this time w/o further consideration and planning for how it > would impact the platform generally. > > —jason --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
