Community
Participate
Working Groups
I have to projects in eclipse, the former (A) depending on the second (B) through a jar built from project B with ant. I routinely rebuild project B with ant every day about a dozen of times, then refresh the project A's build path to make the changes visible in Eclipse. The problem is that now Eclipse marks the jar file invalid: "Archive for required library: B.jar in project A cannot be read or is not a valid ZIP file." The jar file in question is OK, if I use the same jar in our Jenkins environment to build project A, it builds without errors. This happened the second time this week. The last time I tried a number of things to fix the problem: clean & build my whole workspace, restart eclipse etc. Finally I removed my full workspace, including the .metadata directory within, then checked it out again from our SVN repository (losing most of my precious workspace settings in the process), which finally solved the problem. This makes me suspect that Eclipse misdiagnoses the jar file then caches the invalid status somewhere in .metadata and fails to fix the invalid status later. Please at least provide a workaround, for example: which part of the .metadata directory should I erase or modify to force eclipse to reconsider about the jar files in use? -- Configuration Details -- Product: Eclipse 1.4.2.20120131-1457 (org.eclipse.epp.package.java.product) Installed Features: org.eclipse.jdt 3.7.2.v20120120-1414-7z8gFcuFMP7BW5XTz0jLTnz0l9B1
A similar (although incomplete) story I found googling earlier: http://www.eclipse.org/forums/index.php/t/242820/ Note that: - there's no "OK, that fixed it." post at the end of the thread, - also the proposed fix in Daniel's reply is admittedly a simple sanity check: "but if the original files are ok, the copy should be the same". So there's no trace of _that_ case being fixed. Just thought I post this, before I get a "worksforme" on my bug report...
Created attachment 213139 [details] .metadata/.log part Here's a part of the .metadata/.log logfile. Looks like it all started with a simple FileNotFoundException (I guess the problematic jar file was being built while a refresh was in progress on the project depending on it). After that came a few "Invalid ZIP archive" messages. Next one is a Java Model Exception. The last message is another "Invalid ZIP archive". Identical "Invalid ZIP archive" messages also appear later on in the log (not present in this attachment).
I guess I found a workaround (have to check it again when I run into this situation). 1. Close Eclipse. 2. Delete the following caches from the workspace: .metadata\.plugins\org.eclipse.jdt.core\invalidArchivesCache .metadata\.plugins\org.eclipse.jdt.core\nonChainingJarsCache (Deleting only the first one may work, I still have to verify this.) 3. Start eclipse. 4. Clean project depending on the problematic jar.
Jay, please follow up, thanks.
(In reply to comment #3) > .metadata\.plugins\org.eclipse.jdt.core\invalidArchivesCache > .metadata\.plugins\org.eclipse.jdt.core\nonChainingJarsCache > > (Deleting only the first one may work, I still have to verify this.) Yes, deleting the first one would have been enough. That said, it would be better to have the file-not-found scenario addressed. I will take a look at it.
I believe this is same as bug 357425 and got fixed in 3.8 M3. The fix wasn't back-ported since it was an uncommon scenario. Could you please try with the 3.8 M6 build.
This is same as bug 357425. *** This bug has been marked as a duplicate of bug 357425 ***
(In reply to comment #3) > I guess I found a workaround (have to check it again when I run into this > . > . > . > 4. Clean project depending on the problematic jar. I'm running into this very same problem when building a Grails project with Eclipse 3.7.2 and STS 2.9.1. However, when I clean the project, nothing happens and I still see the original Build Path Problem in the Problems view: Archive for required library: 'C:/Users/Mirko/.ivy2/cache/net.sf.ehcache/ehcache/poms/ehcache-1.7.1.pom' in project 'elect-admin' cannot be read or is not a valid ZIP file The supposedly broken JAR is an Ivy dependency, and all JARs listed in that POM look alright. Are there any other work-around steps I could try?
(In reply to comment #8) > Are there any other work-around steps I could try? You could try the one mentioned in comment #3 and 5. Which build are you using, by the way?
(In reply to comment #9) > (In reply to comment #8) > > Are there any other work-around steps I could try? > > You could try the one mentioned in comment #3 and 5. > Which build are you using, by the way? Hm... that's exactly the work-around that I tried, but unfortunately a subsequent "clean" does not do anything, i.e., I don't see any progress report about the clean actually being triggered. I'm using build M20120208-0800.
(In reply to comment #10) > Hm... that's exactly the work-around that I tried, but unfortunately a > subsequent "clean" does not do anything, i.e., I don't see any progress report > about the clean actually being triggered. > I'm using build M20120208-0800. I don't have an explanation for that. I am assuming you have 'Build automatically' enabled. Did you get a chance to try with 3.8M6, BTW?
This doesn't seem to be a duplicate of bug 357425, as bug 357425 was a regression of another bug fixed around 3.8M3. As the changes were not on 3.7.2, this shouldn't have been a duplicate. Hence, reopening. At the same time, I couldn't reproduce the problem with 3.7.2 using steps in comment 0 and comment 2. I could see the jar names in the file invalidArchivesCache. I just do a refresh and everything does seem to be set properly. Attila Csipak/Mirko Raner, Can you try to give us some reproducible test case?
Sorry, I do not have a stable test case, althought the problem still occurs spontaneously since the original bug report. Sometimes it takes 2 weeks to reouccur, sometimes I get 2-3 cases the same day. It's not clear how the bug can be forced to happen. I also guess that initiating a workspace refresh, while an ant task building the problematic jar is still in progress may be the cause of the problem.
(In reply to comment #12) > Attila Csipak/Mirko Raner, > Can you try to give us some reproducible test case? Unfortunately, to recreate the problem you would need a rather complicated workspace set-up as well as several third-party plug-ins; our build process is pretty involved, unfortunately. In our particular case the problem occurs for building a Grails project that uses Ivy dependencies, but I'm afraid I can't easily reduce the problem to a simple test case.
OK, I encountered it again, new details: 1. The situation was the same as I described in comment #13, e.g. overlapping ant build and refresh. 2. At first I didn't get "cannot be read or is not a valid ZIP file" error marking anywhere, but a java source file marked a couple of imports invalid because it didn't find the package of the imported classes. The strange thing was that while _in_ the editor all appearences of the affected classes were marked as errors, the file itself didn't get marked as erroneous, neither did it show up in package explorer, or in the Problems view. (Of course the affected classes were are residing in the problematic jar.) 3. I nagged eclipse for a while to recognize the jar (rebuild, refresh etc.). The next strange thing came when I opened the referenced libraries node in package explorer, and tried to open the problematic jar's node, which wasn't possible. After a while, the usual "cannot be read or is not a valid ZIP file" showed up. 4. I tried my own workaround recipe (comment #3), but it didn't help, so I started experimenting. What solved problem was (read before trying!): - exit Eclipse - delete .metadata\.plugins\org.eclipse.core.resources\.root\*.tree - start Eclipse, which throws a lot of errors, and an empty workspace - import all projects into the empty workspace ... well maybe it would have been less radical to remove only the offending project(s), and re-import them.
For what it's worth I see the same error for a library jar (inside project A, referenced by project B) that another developer on my team added and showed up in my workspace via a git operation. Restarting eclipse, deleting invalidArchivesCache and nonChainingJarsCache, cleaning the project don't solve it for me.
In the absence of a test case, is anybody able and willing to allow Jayaprakash to remote login ?
(In reply to comment #17) > In the absence of a test case, is anybody able and willing to allow > Jayaprakash to remote login ? Sorry, I would love to, but my employer wouldn't like it because we're working on pretty sensitive stuff (elections). I was wondering, though, if it would be possible to add some more detail to the generated error message. In my particular case (see comment #8), the allegedly broken ZIP is actually a POM file. So, if some code in JDT or M2E is indeed trying to open that .pom file as a ZIP archive, that would be clearly a bug. If it is referring to the ZIP file that corresponds to the POM the error message should state which ZIP file that is.
(In reply to comment #18) > I was wondering, though, if it would be possible to add some more detail to the > generated error message. In my particular case (see comment #8), the allegedly > broken ZIP is actually a POM file. So, if some code in JDT or M2E is indeed > trying to open that .pom file as a ZIP archive, that would be clearly a bug. If > it is referring to the ZIP file that corresponds to the POM the error message > should state which ZIP file that is. That explains everything. Indeed, JDT tries to open the classpath entries as archives. And if the file can't be opened it marks that entry with an error. There were more discussion on this on another bug. Let me dig it up for you.
This is the bug I was talking about - bug 364653. The workaround is mentioned in bug 364653, comment #3. Srikanth, I think we should think of a new option to ignore this, like Dani mentioned, in SR1.
That might be the case for Mirko, but mine is definitely an actual jar file, and from Attila's description his is too, so I think Mirko's is actually a separate issue from this one.
This issue continues to reappear with different jar files and significantly impedes my workflow. Is anyone else who is affected using the eGit plugin? I'm still willing to allow Jayaprakash remote login to debug if he is willing.
(In reply to comment #20) > This is the bug I was talking about - bug 364653. The workaround is mentioned > in bug 364653, comment #3. > > Srikanth, I think we should think of a new option to ignore this, like Dani > mentioned, in SR1. We won't add UI or new options in a service release.
I experienced this today, I got around it by deleting the project within Eclipse (but not the contents) and then adding it again. All my previous settings were still stored and the error went away.
I got some log information from Dave and noticed something wrong with the paths of some classpath entries. There were entries such as "/C:/Users/...". Note the preceding '/' and that in windows, we have '\' in absolute paths. But I don't see any evidence to say this is exactly what is causing the problem, because what Dave experienced on this particular occasion is not really the bug. It appears to be a genuine case of the JAR file not being present because of some resource change, such as git switch branch operation. However, the invalid paths might have played a role in the actual bug. Interestingly, the same classpath entry seem to be accessed with a proper paths, both relative and absolute paths, at various points of time. But in those case, we either have the relative path with the '/' or full path with "\" as expected. What I mentioned earlier seems to be a case of wrongly converting a path from absolute to relative, though at this point I am not sure where things go wrong. Further investigation might take some time, as I am busy with other work right now. However, if anyone is interested in looking at it and posting a patch, you are welcome.
Thanks, Jay, for looking into the issue and the log I provided. For the case that occurred while the debug logging was enabled, I didn't verify that the file was actually present and valid (aside from a git status that didn't complain it was missing or modified). In previous cases where this issue has occurred I have manually checked that the file was present and valid, and every time I have checked it has been. I will keep debug logging enabled and the next time it happens do a manual check as well. I think the '/' versus '\' idea is an interesting one. The issue does seem to happen (at least sometimes) after switching git branches from a cygwin command line, so I wonder if there could be anything in play there. For anyone else who has encountered this issue, are you using cygwin and/or git?
The issue happened again today after I switched from a git branch that did not contain the jar file in question to a git branch which does contain it. I verified this time that the file does exist in my file system, it is a valid archive file, and eclipse can see it in the Navigator view. Jay, I will email you the debug console log again in case that helps.
I have since seen this occur a couple more times, but had one other interesting observation. One time that it happened, (when I made the previous comment), I was able to resolve the problem by editing removing the offending JAR from the build classpath, then adding it back again. Just now the issue occurred again, and removing the offending JAR from the build classpath then adding it back again does not resolve it. So it seems that some cases may be different than others.
I just encountered this bug. Some here was using Eclipse 3.3.1.1 to create a project. They zipped the project up and sent it to me. I unzip the project and imported it into my workspace (Eclipse 3.7). When I tried to open the project I was getting this error. I opened the .project file in a text editor and found a <linkedResources> section. Inside this section was <name>, <type> and <location>. The <name> was the library generating the error message. The <type> was 1 and the <location> was a path to the jar file, including the jar file name, on my colleague's machine. I do not have this directory. If I close Eclipse, delete the <linkedResources> section, save the .project and restart Eclipse the problem goes away.
Waiting for a reproducible test case does not sound like the winning strategy for tackling this. I know at the moment everyone is busy, but at some point, we should invest some cycles to come up with various hypotheses and try to validate them - CCing other committers to see if some one has a ready theory.
This is happening to me as well or at least some flavor of it. The symptom seems to be that the jar file that my projects are dependent on is changed outside of Eclipse (via our build system that creates a new jar). The issue seems to go beyond Eclipse though as I cannot even open the new jar file on the file system (jar -tvf myapp.jar): java.util.zip.ZipException: error in opening zip file It is as though the file handle is somehow corrupted. Not sure if this is caused by Eclipse or if the Eclipse issue is a symptom of the file handle corruption. I am on Windows 7. Restarting Windows was the only way to resolve the file handle issue (so far).
Ed's issue sounds like it may not be the same as this eclipse issue which happens even when the jar is completely accessible on the file system.
(In reply to comment #32) > Ed's issue sounds like it may not be the same as this eclipse issue which > happens even when the jar is completely accessible on the file system. Right, that doesn't look like an eclipse bug to me.
The problem went away for me only after deleting (with eclipse closed): .metadata/.plugins/org.eclipse.jdt.core/externalLibsTimeStamps I had tried to delete these two earlier: .metadata/.plugins/org.eclipse.jdt.core/invalidArchivesCache .metadata/.plugins/org.eclipse.jdt.core/nonChainingJarsCache But just deleting those two didn't solve the problem. For the record, here was the specific message for me: MESSAGE Invalid ZIP archive: /home/steveo/.m2/repository/com/google/code/simple-spring-memcached/spymemcached/2.7.3/spymemcached-2.7.3.jar I checked permissions on the jar file (world readable) and tried jar -tf /home/steveo/.m2/repository/com/google/code/simple-spring-memcached/spymemcached/2.7.3/spymemcached-2.7.3.jar which is able to list the contents of the file. I found the files to try to delete using grep: $ ack-grep -a spymem Binary file .plugins/org.eclipse.jdt.core/externalLibsTimeStamps matches Binary file .plugins/org.eclipse.jdt.core/nonChainingJarsCache matches ... There were a couple other files that I didn't delete as well that match specific project files.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
