[MARTIFACT-75] Don't print stack trace from correctly functioning code

[elharo]

No description provided.

[hboutemy]

this does not really solve the issue, but just makes it less visible:

[WARNING] Corrupt jar file /Users/hboutemy/dev/maven/plugins/tools/maven-help-plugin/target/reference/org.apache.maven.plugins/maven-help-plugin-3.5.0.pom
zip END header not found

as fixed in #67, trying to open a .pom file as a jar is just a bug, not corrupted zip

when an issue is found openeing archive, having the full stack trace is IMHO useful to differentiate between bug like currently vs reqally corrupted zip (like nobody ever reported)

[elharo]

I agree this doesn't solve the issue. However, it does make it more visible. The real problem in this case is,as you noticed, that we're trying to open a pom as a jar. However, this log message now makes that a little more apparent since the problem is not obscured by an extra page of stack dump.

And in the more likely case where the jar file actually is corrupt (which does happen) this will also be clearer.

[hboutemy]

sorry, I don't find hiding the stacktrace improving visibility, nor putting original message on a newline: probably matter of taste
Differentiating ZipException from generic IOException is a nice idea, to differentiate file reading fro corrupted jar

FYI, I closed MARTIFACT-75 based on #67 = original code was not working properly (regression introduced in MARTIFACT-62): don't hesitate to create another Jira issue for that corrupted jar display

[hboutemy]

thinking again at it: if we do that, we need to display the exception class
like if the exception message was the first line of the stacktrace, as it brings useful info = the type of issue

with that pattern, ok, the rest of the stacktrace can be ignored

[michael-o]

I wouldn't suppress exceptions

[elharo]

MARTIFACT-75 is a very interesting and uncommon exception pattern. If I'm following the discussion correctly, there is in fact a bug in the maven-dependency-plugin code that causes it to load the wrong file. That leads to this zip exception. So yes, in this one case the stacktrace does help.

However that's the zebra case. The horses cases (i.e. when you hear hoof beats think horses, not zebras) is that the file is in fact corrupt. I have seen corrupt jar files in Maven repos, central included, many, many times over the years, though more frequently when I was in the business of deep scanning large dependency trees in groups of many projects. Back when I was doing that, it was pretty routine that somewhere in a scan of thousands of artifacts, you'd hit one or two corrupt jars.

Stack traces should be reserved for program bugs, usually indicated by runtime exceptions. In this very specific case, it turns out the ZipException actually is a program bug so a stack trace is helpful, but the vast majority of the time a ZipException or IOException indicates a problem in external data and not in the program itself. In that far more common case, the stack trace is unactionable noise.