Add amount of warnings encountered as a maven "placeholder"

Aaron B :

In maven you can use 'placeholders' like ${maven.build.timestamp} for example. Is there a way i could get a placeholder, lets say ${warnings}, which contains the number of warnings encountered while building the project?

Example:

"[!] This Build is version ${project.version}, and was compiled on ${maven.build.timestamp} UTC." + System.lineSeparator() + "[!] ${warnings} occured while building this build, and there were ${errors} errors."
adq :

Maven doesn't do any post-processing with log files - it only uses SLF4J implementation of logging which has some configuration. This means that Maven doesn't have any property related to log files that would show count of certain type of logging messages. This means you'd have to do that part yourself, and then attach it to a property so you can use property substitution. This makes it a relatively time-consuming task with what seems like little reward.

Arguments why it's not worth it

  1. Warning message format is dependent on individual plug-ins - so this means that if the plug-in developer(s) decided that they'd put multiple warning log statements for single warning, you can't decide whether it's one warning or three. Same will be true if they decided to put all warnings in one log entry for some reason.
  2. There is no point in counting errors - the convention for Maven API is to throw an exception as soon as you get an error during plug-in execution that you can't handle, and thus ending the build with failure.
  3. The solution to this problem requires processing the log file - which means you have to redirect the stream and, in doing so, restricting functionality.

Okay, I want it anyway, what do I do?

You just have to:

  1. Redirect SLF4J log output to a file (which is explained in the link given, and SLF4J javadoc)
  2. At the end of Maven lifecycle, execute post-processing of the log file, count the messages which have a particular logging level (i.e. WARN), and save that number to a property (i.e. warnings)
  3. Write output message after the post-processing, and do property substitution (i.e. ${warnings})

Given all that, I'd say it's not really worth the effort just to display the amount of warnings.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=419782&siteId=1