Community
Participate
Working Groups
Build Identifier: 20100218-1602 This is happening while building an rcp product using PDE-Build and the p2.gathering=true property. I have a feature that has root-properties to include the jre in generated product. As build process removes the executable bits when copying the files from the filesystem I'm trying to re-add them using the root.permissions.755 property. However this doesn't seem to work, the generated zip file (or tar.gz) doesn't have those bits set on the files mentioned in properties line. I'm currently using just root.permissions.755=jre/bin/java I've also noticed that using a comma-separated list in that property doesn't work either, i.e. after adding the launcher name to the above neither the launcher nor the java binary have the executable bit set. Reproducible: Always Steps to Reproduce: 1. add root.folder.jre=/path/to/jre to the build.properties of a feature included in your product 2. add root.permissions.jre=jre/bin/java to the build.properties of the feature 3. Build an rcp product using p2.gathering=true The generated .zip file will not have executable bits set on the jre/bin/java binary included in it.
Apparently this is fixed in Eclipse 3.6, I just replaced our eclipse 3.5 installation that is being used to drive the PDE build with 3.6 and got the properly set executable bits on jre/bin/java. I've then tried to use jre/bin/* in the permissions property but that failed with /var/lib/hudson/jobs/Experimental PDE Build/workspace/build/package.org.eclipse.pde.build.container.feature.linux.gtk.x86.xml:1174: fullpath attribute may only be specified for filesets that specify a single file. So it seems that this is still not work. I'm mostly mentioning this to ask wether I should open a new report about that or adjust the title/description of this one?
I changed the title. The original fix was bug 282260. The problem here is the zipfileset http://ant.apache.org/manual/Types/zipfileset.html used to specify the permissions. If we think we are only dealing with one file we use the "fullpath" attribute, otherwise for directories we use "prefix". I don't see any real reason we can't just use prefix all the time.
A workaround for this should be to use the native zip or tar for creating the archive. This is controlled by the archivesFormat property in the builder's build.properties file. Use something like: archivesFormat = linux, gtk, x86 - zip The default is antZip which has this problem.
(In reply to comment #3) > A workaround for this should be to use the native zip or tar for creating the > archive. > > This is controlled by the archivesFormat property in the builder's > build.properties file. Use something like: > archivesFormat = linux, gtk, x86 - zip > > The default is antZip which has this problem. Using zip or tar didn't help, all files under jre had no executable bits after unpacking the resulting tar/zip. And yes the original files used from the filesystem do have the bits set :)
Created attachment 177476 [details] patch
fixed
