Community
Participate
Working Groups
When publishing, if the passed in list of files to include in the artifact is all files and no directories then the resulting jar won't have any directory entries. This is likely to cause problems for bundles that expect to have directory entries. See for example bug 274079. When creating a zip, we will need to keep track of directory entries and if we are adding a file for which the parent directory does not have an entry, we should create one.
Created attachment 133666 [details] potential patch Patch will add directory entries for files. META-INF/MANIFEST.MF is special cased, it should come first in the jar, generally it is up to the caller to make sure this is true, but we should not be inserting the META-INF/ directory entry before the manifest. I've added some checks to p2.tests/FileUtilsTest As well as pde.build.tests/PublishingTests, in particular PublishingTests.testPublishBundle_simple also checks that the manifest comes first.
The patch looks good to me. Two comments: 1) Did you intend to make FileUtils.zip(ZipOutputStream, File, Set, IPathComputer, Set) public? The one that takes the directoryEntries set. 2) Should FileUtils.zipDirectoryEntry(ZipOutputStream, IPath, long, Set) simply throw the IOException that may occur while creating the directory entry? The previous code would only catch (and ignore) ZipExceptions in zipDir(). There is a comment about doing something about duplicate entries. I'm not sure this is still relevant not that we check teh directoryEntries set.
1) I did intend to make this public. Any callers of the non-Set version will need to pass a set if they do this in a loop on the same output stream. There are no current callers that I see that do this (the only other callers now don't do a loop so are happy with the default new HashSet()). 2) I have changed to throw IOException and catch ZipException as suggested. I also updated the catch comment, the exception is not expected to happen since we are checking the set first. I have released and tagged these changes for I20090429-0100
I released this bundle to basebuilder, ran a test build and Andrew verified that the bundles look as expected. This fix will be in the I20090429-1800 build.
*** Bug 274079 has been marked as a duplicate of this bug. ***
