maven-shade-plugin
maven-shade-plugin copied to clipboard
apache
[MSHADE-248] shading fails with "error in opening zip file" if createSourcesJar=true and an invalid sources jar file is encountered
Ian Springer opened MSHADE-248 and commented
Downloading: https://foo.repo.com/nexus/content/groups/foo/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar
[WARNING] Checksum validation failed, expected <!DOCTYPE but is b95d8d7d1a57cf46d9f0e924f8864f94159bffd3 for https://foo.repo.com/nexus/content/groups/foo/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar
Could not validate integrity of download from https://foo.repo.com/nexus/content/groups/foo/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar: Checksum validation failed, expected <!DOCTYPE but is b95d8d7d1a57cf46d9f0e924f8864f94159bffd3
[WARNING] Checksum validation failed, expected <!DOCTYPE but is b95d8d7d1a57cf46d9f0e924f8864f94159bffd3 for https://foo.repo.com/nexus/content/groups/foo/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar
Downloaded: https://foo.repo.com/nexus/content/groups/foo/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar (2 KB at 1.3 KB/sec)
And then:
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 18.486 s
Finished at: 2017-02-07T11:13:11-05:00
Final Memory: 72M/977M
------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (shade) on project jclouds-shaded: Error creating shaded jar: error in opening zip file /Users/ips/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar -> [Help 1]
bsh is a transitive dep of one of the jars I am shading. Since I can't control the fact that they have an invalid sources jar published, the shade plugin should be more forgiving and just log a warning and skip the bsh sources jar when building the shaded sources jar.
Affects: 2.4.3
Robert Scholte commented
According to Central there's no sources-jar for this bsh version. Which makes me wonder why it seems to download a jar anyway. Would be nice if this could be fixed at the source (your foo.repo.com), otherwise we need to add include/exclude options for every kind of created jar.
Michael Osipov commented
This come also come from a company proxy or a repo manager. Please clarify.
Ian Springer commented
It's our internal Nexus server, which proxies central and a bunch of other public repos.
Ian Springer commented
Here is the content of bsh-2.0b4-sources.jar:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<style type="text/css">
html, body, #partner, iframe {
height:100%;
width:100%;
margin:0;
padding:0;
border:0;
outline:0;
font-size:100%;
vertical-align:baseline;
background:transparent;
}
body {
overflow:hidden;
}
</style>
<meta content="NOW" name="expires">
<meta content="index, follow, all" name="GOOGLEBOT">
<meta content="index, follow, all" name="robots">
<!-- Following Meta-Tag fixes scaling-issues on mobile devices -->
<meta content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" name="viewport">
</head>
<body>
<div id="partner"></div>
<script type="text/javascript">
document.write(
'<script type="text/javascript" language="JavaScript"'
+ 'src="//sedoparking.com/frmpark/'
+ window.location.host + '/'
+ 'tierraexpired'
+ '/park.js">'
+ '<\/script>'
);
</script>
</body>
</html>
I have seen this issue in the past with invalid or missing Maven artifacts getting erroneously saved to local repos (or Nexus) as HTML files.
Michael Osipov commented
Extremely unlikely. Your setup seems to be really broken. Nexus (Jetty) will never deliver something for sedoparking.com. Inquire with your Nexus admin first. Moreover, you can enable content validation on Nexus side for proxy repositories.
Ian Springer commented
What is extremely unlikely? I've been using Maven for like 12 years, and I have seen the HTML thing a bunch of times in the past.
Michael Osipov commented
Unlikely that Nexus would deliver such a content. Especially becasue this JAR does not exist on Central.
Ian Springer commented
Our Nexus repo has been running for 5 years or so, so my guess is the jar did exist on central or some other repo we proxy at some point in the past 5 years.
In any case, it sounds like you don't agree the shade plugin should be more lenient. That's cool.
Michael Osipov commented
In any case, it sounds like you don't agree the shade plugin should be more lenient. That's cool.
I didn't say that. I wanted to understand the root cause first. As you can see, Maven already gives you a warning that there is something wrong with the JAR. Basically, no plugin interacting with ZIP files does a content validation. It is done here with java.util.jar.JarFile. During dep download it is assumed that the ZIP file is validated against its checksum and in case of a problem you'll see the warning. What would you expect to see? Skipping a ZIP isn't a good way to go. Either all or nothing.
Ian Springer commented
Well, it turned out in this case, I am able to fix the root cause by deleting the invalid artifact from my Nexus repo. But I am thinking if there was an invalid sources jar on some public repo that I didn't control, it would be frustrating if that prevented me from building a sources jar for my shaded jar. I think it would be ideal if the shard plugin logged something like:
WARN: Error in opening sources jar for inclusion in shaded sources jar: invalid zip file /Users/ips/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4-sources.jar. org.beanshell.bsh:bsh sources will be omitted from the shaded sources jar. To fix this issue, try deleting the file from your local repo. If the problem persists, a corrupt artifact was probably published to a remote repo.
Michael Osipov commented
Alright! Robert Scholte, what do you think, can we have a better message? Do you even have that kind of context information at the time of the exception?
Robert Scholte commented
If it would have been the main jar, you would have a real issue which would require the same kind of actions. The corrupt jar isn't a jar so hence it cannot be opened. I consider this too rare to fix.
Elliotte Rusty Harold commented
I've certainly seen problems like this before, multiple times, though not with the shade plugin. In general it would be nice if Maven did validate files it downloads and reads from the local repo, and took a more deliberate approach about what to do when one is corrupt. Today a single corrupt file can cause weird, hard to understand failures with bad error messages far away from the root cause, depending mostly on which chunk of code notices and finally reacts to the error.