Colorize output

[schumacher-m]

I want to bounce some ideas if it makes sense to enhance the tool to visually give (more) feedback on passing or broken migrations (similar to most test frameworks red->green schema)
I usually let the tool run and continue on something else - i still notice that the log is moving and for me it helped that it spitted out a red text on a failure as this usually gets my attention immediately.

In our internal version of mybatis-migrations we also red-color the exception to separate them from the migration content that is also printed out and made the tool less chatty by removing the status lines. If you run many and large migrations it helps to quickly jump to a red part and see what was wrong as you tend to lose where the error started.

Nonetheless. I stripped our version down to just printing the SUCCESS or FAILURE, exceptions in different colors to have a small increment and hope we can just build-up from there.

Activate it by adding "--color" as a parameter.

(pom.xml change was done to build locally)

[simonetripodi]

This is IMHO a nice idea, I am +1 to apply the Pull Request

@schumacher-m I think you can make the ConsoleColors as an interface rather just a regular class, since it declares constants only and, in order to apply the commit, you need to revert the version in the pom.

Very well done!

[schumacher-m]

Alright. I rebased and dropped the pom change.

[simonetripodi]

@schumacher-m if you don't want to make the _ ConsoleColors_ class as an interface, drop the public modifier and implement the default constructor as private since it doesn't have to be instantiated, OTOH it looks good - any chance you can attach a screenshot for the audience, please?

[schumacher-m]

I'm not against the interface change - just doing this work thing and I'm bad at multitasking ;)
I'll prepare the screenshot in the evening.

[simonetripodi]

awesome @schumacher-m , just awesome, thanks for this great addition 👍

[schumacher-m]

Here is an example:

[simonetripodi]

Shiny like a sunshine 👍

I personally would like to have this behaviour enabled by default, can be suppressed via an option, i.e. --no-highlight (highlight is a best therm in such contexts, IMHO)

What other people think? @cbegin ?

[hazendaz]

👍

[harawata]

Looks nice. Thank you, @schumacher-m !

Regarding the default, I'm fine with either, but no-color (or no-highlight) might be safer.
To avoid typing it every time, I'll make it configurable in the properties file later.

[schumacher-m]

(Not sure why it complained about the formatting)

Yes. I think it is more compatible to have it opt-in. I was initially thinking that the added color might break some scripts if they for example grep for the whole success string - might be too constructed though.

Enabling this in the prop file would be ok.

[h3adache]

This looks good @schumacher-m but CommandLine implementing ConsoleColors just to bring in the colors is a bit odd. Why not just static imports if you are that concerned about the colors.

[schumacher-m]

Well initially it was just a class I've imported (see: 6be27e9)

In the end I was indifferent about either way. What would you suggest?

[h3adache]

importing it makes more sense. the public static final are unnecessary anyways as interface values are already public final and static by default but you already made that change. So it's just adding the static imports or quantifying it.
In the future I would love to see the console writing be split out into a strategy so that you can use color console/logging as a strategy across not just the final error and status lines but this is a great feature on it's own.

[h3adache]

To clarify, I mean to give colors to warnings or pre/post hooks etc.

[schumacher-m]

Ok. Let me switch it back to just a class for now. We can continue on the output. I also like to make it less maven-esque (or at least define some sort of different formatter)

[h3adache]

There's some confusion here, I meant keep it an interface but don't implement it.

[schumacher-m]

So I reverted the interface change - probably best to squash this PR. I only see the formatting conflicts on github.

[schumacher-m]

So after some confusion I rebased everything (also with latest master in upstream) and here it is again ;)

[schumacher-m]

In the future I would love to see the console writing be split out into a strategy so that you can use color console/logging as a strategy across not just the final error and status lines but this is a great feature on it's own.

I'd like to dive into it - since this is somewhat the same direction I wanted to go with this.
Shall we just put it as an issue for better discussion?

[h3adache]

That would be great @schumacher-m! Thanks for the work here!

[simonetripodi]

thanks for the awesome work @schumacher-m , much more than appreciated!

thanks @h3adache for merging the PR - I love to see this modification checked-in our codebase! 👍

[harawata]

Hi all,
With the latest SNAPSHOT, it's now possible to specify color=true in migration.properties instead of specifying --color every time.