Community
Participate
Working Groups
Starting with at least AspectJ 1.6.5 the following problem has been discovered: unpacked aspectjtools.jar file has classes and directories with 0-0-0 permissions. E.g. ---------- 1 xxx xxx 1432 2007-10-23 18:07 about.html d--------- 2 xxx xxx 30 2009-06-17 20:42 ant_tasks/ -rw-r--r-- 1 xxx xxx 8181 2009-02-28 13:15 aspectj_1_5_0.dtd ---------- 1 xxx xxx 804 2007-10-23 18:14 CDC-1.0_Foundation-1.0.profile ---------- 1 xxx xxx 938 2007-10-23 18:14 CDC-1.1_Foundation-1.1.profile An attempt to build an RPM package for a product with AspectJ dependencies is apparently failing because once the file is unpacked there's very little can be done with such files. Another jar file from the same distribution (aspectjrt.jar) doesn't have that problem. Please fix if if possible.
I'm trying to look into this, I'm on Windows/Mac. jar -tvf won't show me the permissions so I did a jar -xvf to unpack aspectjtools.jar - in my expanded folder the files are all 644 (rw-r--r--). I'm not saying there isn't a problem here, I'm just trying to find a nice way to confirm there is. What tool were you using on linux to show jar permissions?
i was going to build a little jar explorer to show me the permissions of the entries, but I can't actually see where the permissions are stored inside the file ....
Actually, I've been using 'unzip' utility and I can confirm that 'jar' works property and I don't see incorrect permission after 'jar xf' command execution. Apparently, this isn't an issue with aspectj* jar files - this is a limited or incompatible implementation of unzip program. Please don't build that jar explorer :) and feel free to close the bug.
thanks for getting back to me :)
Can we re-open this? Looks like the aspectjtools jar still has lots of files w/o permissions set. jar xf will set permissions even if they're not set, while unzip preserves the permissions in the jar file. Re-packing tools used by rpm use unzip so we have to disable jar re-packing in order to work around this. common1 (trunk)$ mkdir temp common1 (trunk)$ cp build/hadoop-common-0.22.0-SNAPSHOT/lib/aspectjtools-1.6.5.jar temp/ temp (trunk)$ unzip aspectjtools-1.6.5.jar temp (trunk)$ ls -al ... drwxr-xr-x 5 eli eli 4096 2009-06-17 20:42 org -rw-r--r-- 1 eli eli 26 2009-06-17 20:42 org.eclipse.jdt.core-empty ---------- 1 eli eli 731 2007-10-23 18:14 OSGi_Minimum-1.0.profile ---------- 1 eli eli 751 2007-10-23 18:14 OSGi_Minimum-1.1.profile ---------- 1 eli eli 715 2007-10-23 18:07 plugin.properties ---------- 1 eli eli 1337 2007-10-23 18:07 plugin.xml ---------- 1 eli eli 794 2007-10-23 18:14 profile.list ---------- 1 eli eli 890 2007-10-23 18:14 systembundle.properties d--------- 2 eli eli 4096 2009-06-17 20:42 testdata
ok, feel free to reopen.
I don't have that option since I'm a normal user and didn't create the bug.
Per Eli's request
Actually, I agree that the problem is valid: we have worked it around by exactly turning off RPM repackaging. However, if having an RPM package for Hadoop distro is the must requirement then the problem needs to be fixed 'cause otherwise use of aspectjtools.jar becomes an issue.
