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.
Summary: | verify-class-linkage failing with zip exception | ||
---|---|---|---|
Product: | apisupport | Reporter: | davidparks <davidparks> |
Component: | Harness | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows Vista | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
davidparks
2008-08-04 03:08:31 UTC
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. |