Bugzilla – Full Text Bug Listing
| Summary: | root.permissions property does not support wildcards/patterns | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Meng Xin Zhu <kane.zhu> | ||||||
| Component: | Tycho | Assignee: | Jan Sievers <jan.sievers> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | minor | ||||||||
| Priority: | P3 | CC: | jan.sievers, kane.mx, pwebster, t-oberlies, thanh.ha | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 386599 | ||||||||
| Attachments: |
|
||||||||
also see bug 352251 comment#1 (In reply to comment #1) > also see bug 352251 comment#1 I see. It's still a limitation. I tried to add two lines of changing permission in build.properties, only the last one is generated into metadata. No workaround for it. root.solaris.gtk.sparc.permissions.777=jre/1.6.0_21/bin/java root.solaris.gtk.sparc.permissions.777=jre/1.6.0_21/bin/java_vm (In reply to comment #2) > I tried to add two lines of changing permission in build.properties, only the > last one is generated into metadata. No workaround for it. > > root.solaris.gtk.sparc.permissions.777=jre/1.6.0_21/bin/java > root.solaris.gtk.sparc.permissions.777=jre/1.6.0_21/bin/java_vm This is expected for a properties file, isn't it? IIRC the value can be a comma-separated list. Still, you are right that this is a missing feature/bug. But in all static cases you should be able to work around the problem by specifying an explicit list of files. (In reply to comment #3) > (In reply to comment #2) > > I tried to add two lines of changing permission in build.properties, only the > > last one is generated into metadata. No workaround for it. > > > > root.solaris.gtk.sparc.permissions.777=jre/1.6.0_21/bin/java > > root.solaris.gtk.sparc.permissions.777=jre/1.6.0_21/bin/java_vm > This is expected for a properties file, isn't it? IIRC the value can be a > comma-separated list. You're right, comma-separated list is a workaround. Changed title from tycho incorrectly handles the 'chmod' touchpoint action to root.permissions property does not support wildcards/patterns to better describe the limitation. We've hit this while building the Eclipse Platform using CBI - maven/tycho. root.linux.gtk.x86.permissions.755=*.so* Created attachment 223373 [details]
Minimal project to reproduce
Attached is a minimal project to reproduce the issue.
Created attachment 223381 [details]
patch (needs tests)
there are currently problems to push to gerrit, so here is a first version of a patch. needs tests.
https://git.eclipse.org/r/#/c/8624/ ... more complicated than one would assume at first glance |
1. specify the root files and 'chmod' action in build.properties like below, root.linux.gtk.x86= jre root.linux.gtk.x86.permissions.777=jre/*/bin/* 2. use tycho to deploy the RCP application as eclipse repository. Tycho creates the wrong metadata for 'chmod' action like below, <instructions size='1'> <instruction key='install'> chmod(targetDir:${installFolder}, targetFile:jre/*/bin/*, permissions:777); </instruction> </instructions> However this usage works fine in PDE build. The metadata generated by PDE looks like, <instructions size="1"><instruction key="install"> chmod(targetDir:${installFolder}, targetFile:jre/1.6.0_21/bin/java, permissions:777); </instruction></instructions><instructions size="1"><instruction key="install"> chmod(targetDir:${installFolder}, targetFile:jre/1.6.0_21/bin/java_vm, permissions:777); </instruction></instructions><instructions size="1"><instruction key="install"> chmod(targetDir:${installFolder}, targetFile:jre/1.6.0_21/bin/javaws, permissions:777); </instruction></instructions> PDE build helps find all files that match the specified pattern, then create touchpoint action for them one by one.