DiagnosticListener summary message is obscur and misleading

[rmannibucau]

Affected version

4.0.0-beta-4

Bug description

Current messages always logs:

• an aggregate
• code instead of pseudo english messages to be understandable
• is always logged whereas messages are already logged so if people care they have what they need, aggregate can be a fun way to encourage people to fix it but actually just having the log is sufficient in 99% of the case and it avoids the duplication

goal here is to

• make configurabe the output
• try to display more meaningful messages

[desruisseaux]

I think that this is a description of pull request #1027. Having more meaningful messages instead of codes is indeed desirable.

I don't think that this is a duplication of the compiler messages. This is a summary. The javac command itself produces such summary at the end of the compilation, with a message like below:

Note: Some input files additionally use or override a deprecated API.
Note: Some input files additionally use unchecked or unsafe operations.
100 warnings
only showing the first 100 warnings, of 1678 total; use -Xmaxwarns if you would like to see more

The Maven Complier Plugin is doing the same thing as the standard javac tool, only separating the warnings by category for helping the developers to choose their -Xlint options if this is what they decide to do.

Allowing users to control whether they want to see this summary would be nice, but it a task for logging configuration. It could be addressed by using name logger in Maven instead of injecting org.apache.maven.api.plugin.Log. With the recent merge of apache/maven#11685, we can try if System.getLogger("org.apache.maven.compiler.summary") produces the desired effect.

[rmannibucau]

I think that this is a description of pull request #1027.

yes just created it to ensure there is a ticket, sory if it was not clear

I don't think that this is a duplication of the compiler messages. This is a summary.

The fact is that you have twice the same info high level, I can see some value in both but not at the same time, therefore the enum to enable to select your preferred style - don't think everyone will want the same.

but it a task for logging configuration

I don't like the fact to make a ton of logger for that purpose and I prefer to keep loggers 1-1 with classes to keep things simple and understandable while we do use simple logger (fork).

System.getLogger("org.apache.maven.compiler.summary")

default impl is JUL and we don't use JUL at all so it would be very not that common for end users.
it also has a very negative effect: now plugins have a broken logging configuration when they do rely on JUL configuration so I'm very mixed about it for now (to be transparent was a pain before already with LogManager)
we did decide to stick to slf4j as backend and have their own API and I think we shouldn't extend it too much if we don't want to break/limit plugin writers more.