Unable to install locally-built eclipse plugin, get "Error reading signed content"

Question

I inherited a largish Eclipse plugin codebase, which builds with Maven Tycho. The full build produces an update site for the plugin.

I've successfully tested the plugin by just running a test instance and specifying the plugins to load, but I'm now trying to install the plugin "normally" from the locally-built update site. In the update site entry, I specified the path to the zip file in the update-site target folder. It was able to present the list of features present in the update site (only the one). I checked that and continued. It got past the license approval and started to install, but then it failed with this:

An error occurred during the org.eclipse.equinox.internal.p2.engine.phases.CheckTrust phase. session context was:(profile=_home_opnfv_eclipse_java-neon_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.CheckTrust, operand=, action=). Error reading signed content. error in opening zip file

From the .metadata/.log file, there is the following unsurprising stacktrace (excerpt):

!ENTRY org.eclipse.equinox.p2.engine 4 4 2016-02-10 18:22:49.495
!MESSAGE An error occurred during the org.eclipse.equinox.internal.p2.engine.phases.CheckTrust phase.
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2016-02-10 18:22:49.495
!MESSAGE session context was:(profile=_home_opnfv_eclipse_java-neon_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.CheckTrust, operand=, action=).
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2016-02-10 18:22:49.495
!MESSAGE Error reading signed content.
!STACK 0
java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:219)
    at java.util.zip.ZipFile.<init>(ZipFile.java:149)
    at java.util.zip.ZipFile.<init>(ZipFile.java:163)
    at org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:209)
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:73)

In searching for other occurrences of this, I've found various issues that seemed to be associated with this, but nothing concrete. I found a few people with the unsubstantiated advice to delete all the "artifacts.xml" files in the Eclipse distribution. As I didn't have any other suggestions, I tried that (saving them in a tar file first), and then restarted Eclipse, then reinstalled, but that had no effect.

I can't tell WHICH zip file this is complaining about. I imagine it's not the main update site zip. I looked at all the jar files present in "target/repository", and none of them are signed. It's not clear to me that they're supposed to be. As far as I know, the build process for this application should be producing a valid update site.

What other info can I provide that would illuminate this?

Update:

I tried removing one zip file from the equation by selecting "Local" instead of "Archive" when I created the update site entry in Eclipse, and instead of selecting "target/.zip", I selected "target/repository", which has the same content as the zip file. Unfortunately, this made no difference. Same error.

Update:

I have no idea whether this is significant, but I noticed that when Eclipse is attempting to install the plugin, it displays the seemingly innocuous "Install Details" page, which lists the plugins to be installed, but I happened to notice that below this plugin list is a "Size:" label, and the value on it is "0 bytes". Is this significant, and if so, what does that indicate?

Update:

After connecting a debugger to the target instance, I was able to discover that the corrupted jar is "$HOME/.p2/pool/plugins/org.eclipse.emf.mapping_2.9.0.v20160201-0859.jar". This file is not zero length, but "jar" and "unzip" report that the file is corrupted. I found four other "org.eclipse.emf.*" jars with a similar problem, and all other jars in the p2 repo are fine.

Now that I know which files are corrupted, what can I do about this? I tried moving the corrupted jar files to another location (and carefully logging the information) and then restarting Eclipse and reinstalling the plugin. It still fails with an error in the "CheckTrust" phase, but this time it reports the full path for the missing jar file.

How do I repair these files? Do I have to find valid copies of them somewhere on the net?

(I've filed a bug report to add the full path to the corrupted zip file in the original exception report.)

Answer 1

What ended up happening here is that for some reason, five jar files in my "$HOME/.p2/pool" tree were somehow corrupted. It's possible this happened when my VM ran out of disk space a couple of weeks ago. I repaired the disk space problem, but it's possible that Eclipse failed to completely write something during that period.

The exception message that I received while trying to install a plugin unfortunately didn't mention WHAT archive file was corrupted. During this process, I filed the following bug report for the defective exception message: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487954 . Someone enthusiastically checked in a fix for this the same day (apparently had been hit by this multiple times).

After I determined which archive files were corrupted, I had to somehow fix those files. This repository isn't like the local Maven repository, where you can just delete corrupted files and let the next Maven build restore them.

I posted this specific question on SO about this: How can I repair a damaged eclipse $HOME/.p2 repository? , and also on the Eclipse Platform forum: https://www.eclipse.org/forums/index.php/m/1723920/#msg_1723920 .

Eike Stepper made me aware of some of the capabilities of "Oomph", the core of the new Eclipse installer. There's a very easy to use "Bundle Pool Analysis" feature that automatically finds corrupted archives in this pool and gives you an action to automatically repair them. This is available from both the "Oomph" preferences in Eclipse, and also in the "Advanced Mode" in the new Eclipse installer.

I've been struggling with this series of problems for almost two weeks now, and it's finally all fixed.