Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322340

Summary:

root file permissions don't work with wildcards

Product:

[Eclipse Project] PDE

Reporter:

Andreas Pakulat <andreas>

Component:

Build

Assignee:

pde-build-inbox <pde-build-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

aniefer

Version:

3.6

Target Milestone:

3.7 M2

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
patch	none

Description Andreas Pakulat

2010-08-11 07:54:04 EDT

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.

Comment 1 Andreas Pakulat

2010-08-11 09:34:00 EDT

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?

Comment 2 Andrew Niefer

2010-08-11 11:19:37 EDT

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.

Comment 3 Andrew Niefer

2010-08-13 11:58:33 EDT

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.

Comment 4 Andreas Pakulat

2010-08-13 12:06:43 EDT

(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 :)

Comment 5 Andrew Niefer

2010-08-25 16:31:28 EDT

Created attachment 177476 [details]
patch

Comment 6 Andrew Niefer

2010-08-25 16:31:52 EDT

fixed