This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Best described by cutting and pasting my posts to Nabble. Note that I guess it's two bugs, the verify-class-linkage (which is more of an 'oversight') and the corrupt jar. I've got a library wrapper module that wraps a netbeans java (non-module) project. The java project is Utility (in subdir 'Game') and the netbeans module project is UtilityWrapper I've used the build.xml override trick to allow netbeans to get the jar from the java project's directory... in other words, I've got this in the project.xml for the wrapper module: <class-path-extension> <runtime-relative-path>ext/Utility.jar</runtime-relative-path> <binary-origin>../../Game/Utility/dist/Utility.jar</binary-origin> </class-path-extension> and this in the wrapper's build.xml <property name="original.project.dir" value="../../Game/Utility"/> <property name="original.project.jar" value="${original.project.dir}/dist/Utility.jar"/> <target name="release"> <echo message="Building ${original.project.dir}"/> <ant dir="${original.project.dir}" target="jar" inheritall="false" inheritrefs="false"/> <echo message="Done jarring ${original.project.jar}"/> <copy todir="${cluster}/modules/ext" file="${original.project.jar}"/> <echo message="Done copying ${original.project.jar}"/> </target> <target name="clean" depends="projectized-common.clean"> <echo message="Cleaning ${original.project.dir}"/> <ant dir="${original.project.dir}" target="clean" inheritall="false" inheritrefs="false"/> <echo message="Done cleaning ${original.project.dir}"/> </target> This is the only real customization I've done to the build process. It echos how all of my library wrappers are implemented (about a dozen of them) and they all work most of the time -- restarting netbeans and clean building usually works when I run into one of the build bugs. Not this time. By tracing the 'netbeans' ant project, I've found that my problem comes from the verify-class-linkage target from harness/common.xml. The value ${cluster}/${module.jar} points to the correct project jar in build/cluster/modules. The jar that it points to exists and is fine (but, to make sure, I unzipped and re-zipped it to make sure there wasn't zip corruption. I've also rebuilt it about 30 times in the last 5 hours so that's not it). I'm far from an ant expert and I don't really know what the verify-class-linkage target is for but it dies with the following zip exception stack: 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:114) at java.util.zip.ZipFile.<init>(ZipFile.java:131) at org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1014) at org.apache.tools.ant.AntClassLoader.getResource(AntClassLoader.java:917) at org.netbeans.nbbuild.VerifyClassLinkage.verify(VerifyClassLinkage.java:302) at org.netbeans.nbbuild.VerifyClassLinkage.execute(VerifyClassLinkage.java:171) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:460) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) 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:114) at java.util.zip.ZipFile.<init>(ZipFile.java:131) at org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1014) at org.apache.tools.ant.AntClassLoader.getResource(AntClassLoader.java:917) at org.netbeans.nbbuild.VerifyClassLinkage.verify(VerifyClassLinkage.java:302) at org.netbeans.nbbuild.VerifyClassLinkage.execute(VerifyClassLinkage.java:171) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:460) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) 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:114) at java.util.zip.ZipFile.<init>(ZipFile.java:131) at org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1014) at org.apache.tools.ant.AntClassLoader.getResource(AntClassLoader.java:917) at org.netbeans.nbbuild.VerifyClassLinkage.verify(VerifyClassLinkage.java:302) at org.netbeans.nbbuild.VerifyClassLinkage.execute(VerifyClassLinkage.java:171) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277) at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:460) at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) And the followup: The jar for a dependency (not the utility project) was built corrupt in the build/public-package-jars dir of the module suite. Deleting it wasn't sufficient... it was re-created corrupt. It didn't export any packages but when I set it to do so (it probably should have although of course that is not the point) the error went away. I think this would have been obvious if verify-class-linkage caught exceptions and displayed useful information... at least, the name of the file being processed. From there I could've at least worked around the bug. I eventually tracked this down by randomly removing dependencies from the wrapper module (once I realized that verify-class-linkage was looking at my dependencies). That worked to isolate the problem. Best, - David
reassign to ant module for evaluation
It should not even be possible to have a (compile-time) dependency on a module which does not export any public packages. How did you manage to get to this situation? Is there some way to reproduce? From looking at the code, I can imagine that if the module specifies some public packages but there are no actual classes in them, an empty ZIP could be created in build/public-package-jars, which some tools may be unable to read. Can fix this: core-main #de4e8d1cf035. <verifyclasslinkage> is not the one catching this exception - it is Ant itself. I can try to improve exception reporting in AntClassLoader for Ant 1.8: http://svn.apache.org/viewvc?view=rev&revision=683997
> How did you manage to get to this situation? Heh... good question. If I remember correctly (capital IF), it was the result of a refactor. I renamed a package with the refactor->rename option which must have thrown the packaging system for a loop. I didn't go back to the properties and reactivate the package for export until... well... see my original message. Yep, that sounds right. I don't remember if the zip was 0 bytes but, in case its useful, I can say that WinRar wasn't able to open the corrupt jar either. So at least it probably wasn't a 'some tools' issue... even random non-java-dev tools couldn't open the zip it produced.
Probably FIXED then. IIRC a ZIP with no entries (which java.util.zip lets you create) is not empty but is short - 18 bytes or something. Again IIRC this can be read by 'jar tvf' but not Ant nor some native ZIP tools. Anyway if the dep had no effective public packages then the fix I put in, which would halt the build with a meaningful error message before trying to use the bad JAR, should be correct. If you used the NB refactoring tool to rename a package, yet the public package metadata in the NBM project was not updated to match, please file a separate bug in the component 'apisupport', subcomponent 'refactoring'.
Integrated into 'main-golden', available in build *200808090201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/de4e8d1cf035 User: Jesse Glick <jglick@netbeans.org> Log: Possible fix for #142733: halt distillation of pubpkgs JAR if some pkgs are specified but do not in fact contain any class files.
I've (finally) confirmed that the refactor was the culprit and submitted as a bug here: http://www.netbeans.org/issues/show_bug.cgi?id=144150
I also filed a JRE bug to include the path in the ZipException.