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: | Jar file corrupted after recompile | ||
---|---|---|---|
Product: | obsolete | Reporter: | John Baker <jbaker> |
Component: | jarpackager | Assignee: | issues@obsolete <issues> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
jarContent file
Original jarContent file Source used to create the jarRecipe |
Description
John Baker
2003-08-20 02:46:26 UTC
Created attachment 11371 [details]
jarContent file
Created attachment 11373 [details]
Original jarContent file
Apparently, when compiling the jar content file the source is not mounted, but there is no indication (no badge on the jarContent node) to indicate this (Probably since there may be another com package that is mounted). So, it seems that the com package is replaced with the mounted com package. I guess this is another instance of the well known jarPackager issue. Could you please describe by words, what happened to the jarContent. It is impossible to browse it if I don't have exactly the same filesystems mounted. A different "com" package replaced the original "com" package because the source was not in a mounted filesystem (the IDE found a different "com" package in the classpath) Created attachment 11394 [details]
Source used to create the jarRecipe
To recreate the original jar content: 1) unzip ejb_all.zip in a filesystem 2) Mount this filesystem (com should be the first package) 3) Create a new Jar Recipe from only the class files (use the filter) and add only the com package 4) Compile the jar recipe (No need to create a web module for this) Thanks for the details. I managed to reproduce the problem on a simpler filesystem. FS A: a A.class FS B: a B.class Now, if jar recipe is created on FS A, with "a" as its content FS A: a A.class JarRecipe a FS B: a B.class It can be compiled, the result is a jar file containing a/A.class. The recipe is then ocpied to FS B and FS A unmounted... FS B: a B.class ! JarRecipe ! a The jar recipe is correctly marked as invalid. But if you compile the recipe anyway , the exclamation marks disappear and the content switches to contain the other a package . The compilation finishes with a jar file containing a/B.class. The problem here seems to be that the corruption, though detected, is ignored, compilation runs anyway and the content is somehow corrupted during it. Can you please verify, that in your case the JarRecipe is also indicated to be invalid after moving it and unmounting the sources, before the recompilation ? Lowering the priority, as it is not so easy to reproduce. Still waiting for the reporter to verify my last question: is the jar recipe marked to be invalid just before the corrupting recompilation ? I need to know if I managed to reproduce it or not. To answer the question, no, the jar is not marked as invalid (no red badge). This defect is easy to reproduce when using the original scenario with J2EE components. This is a long standing architectural issue. JarContent is represented by a list of DataObjects which get messed up when the mounted filesystems change substantially, the files change outside of the IDE ,etc. *** This issue has been marked as a duplicate of 21326 *** |