Community
Participate
Working Groups
Build Identifier: 20110916-0149 In Helios, we have this entry in our .classpath files: <classpathentry kind="var" path="QBO_RT/lib/iam.jks"/> The iam.jks file is a keystore. It needs to be on our classpath in order for our system to run. The iam.jks file is not a Zip file. In Indigo, that same .classpath entry results in a fatal build error, and we are stuck. We can't upgrade to Indigo because of this. We'd like to upgrade to Indigo. The error is: Archive for required library: 'C:/dev/trunk/rt/lib/iam.jks' in project 'bin' cannot be read or is not a valid ZIP file Why does Indigo think a non-Zip file is a Zip file, and how do we make it stop? Reproducible: Always Steps to Reproduce: 1. Put entry in .classpath for file that is not a Zip file. 2. Try to build.
Hi Jim. This change was made on purpose but you can make your setup work: For each affected project set 'Incomplete build path' to 'Warning' on the Compiler > Building property page.
We don't want to have a bunch of warnings in our Problems view. We have 15 projects, and each of them outputs this warning. We run entirely without warnings. Now we have spurious warnings. Instead of a breaking change that can only be overcome by introducing warnings, how about an option in preferences to Treat All Var Entries In Classpaths As Zip Files, and default it to false?
As a workaround you could probably also remove it from the build path and add it to the launch configuration. We should add a separate option for this build path problem so that people can set it to 'Ignore'.
Is there a better way for us to put non-archives on our classpath? We want our Eclipse classpaths to match our Maven build and Tomcat runtime classpaths, and we need various non-archive items (for example, resources) to be on the classpath. We tried moving our keystore to a /resources path and it was still rejected by Indigo as an invalid JAR. We also get this error for other artifacts. For example: Description Resource Path Location Type Archive for required library: 'C:/dev/v44/rt/webapps/qbo/WEB-INF/classes/default.properties' in project 'qbo' cannot be read or is not a valid ZIP file qbo Build path Build Path Problem
Dani, I think we should give it a serious thought for 4.3. I can see people wanting to have non zip files in the classpath, properties file being one example. What do you think? To simplify things somewhat, we might allow the user to specify that a classpath entry is not an archive.
(In reply to comment #5) > Dani, > > I think we should give it a serious thought for 4.3. I can see people wanting > to have non zip files in the classpath, properties file being one example. What > do you think? To simplify things somewhat, we might allow the user to specify > that a classpath entry is not an archive. Why would you need to have this on the *build* path?
(In reply to comment #6) > Why would you need to have this on the *build* path? If somebody wants the build path to represent the run time classpath, they might find this useful.
"If somebody wants the build path to represent the run time classpath, they might find this useful." Exactly. Our build path and runtime classpaths are the same. We've never seen a reason for them to be otherwise, until this problem was introduced.
There is one fix (setup the build path and the launch config correctly) and one workaround (set the incomplete build path severity to 'Warning' or 'Ignore'). If we get more bugs/votes about this we might consider adding an additional option but right now, we have more important things to work on.
"There is one fix (setup the build path and the launch config correctly)" Presumes that ours is not already set up correctly. Maintaining two different classpaths is double-entry bookkeeping, which was not necessary until this problem was introduced. "and one workaround (set the incomplete build path severity to 'Warning' or 'Ignore')." We build with zero warnings, so we can't set it to warning. If we set it to ignore, errors we do care about will be masked. "If we get more bugs/votes about this we might consider adding an additional option but right now, we have more important things to work on." First, do no harm. You introduced a change in behavior. We reported the problem and you said oops. Then you started to argue that the problem is really due to how we configure Eclipse. Finally you said it's not a high priority to fix. If it wasn't high enough priority to fix, why was it high enough priority to break it in the first place? What problem did you think you were solving when you introduced a non-opt-out change to Eclipse's existing behavior?
(In reply to comment #10) > We build with zero warnings, so we can't set it to warning. If we set it to > ignore, errors we do care about will be masked. How about marking the entry with an extra attribute OPTIONAL? This will ensure that the error is not reported. But only caveat is, if the file doesn't exist, that error will be suppressed too.
I should mention that our .classpath files have almost 300 JARs listed in them, so maintaining one for build and another for runtime just for a one-line difference is a pain.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
