Joern Huxhorn reported on the mailing list, that this bug isn't fixed yet. The original mail:
-------------
GRADLE-971, GRADLE-796 and GRADLE-673 are all reported as fixed in m9.
But if I remove the doLast-workaround at https://github.com/huxi/lilith/blob/6677657bb4c9ce710d3dd2a95d61fd97fd64f7e8/config.gradle#L601 the file does still have 644 instead of 755 as permission.
I'm not sure how to proceed… should I reopen GRADLE-971 or should I file a new bug for this problem?
------------------------------------------------------------
Gradle 1.0-milestone-9
------------------------------------------------------------
Gradle build time: Tuesday, March 13, 2012 4:10:09 PM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Ivy: 2.2.0
JVM: 1.6.0_29 (Apple Inc. 20.4-b02-402)
OS: Mac OS X 10.7.3 x86_64
Or is there anything I'm missing? I assumed that this should be fixed now. The tar task using the exact sam copyspec is working as expected.
Cheers,
Joern.
-------------
I've added a integration test to reproduce this error. (https://github.com/gradle/gradle/commit/b3e2c2a88c1e786b76b8414388037ade63c0d549)
In addition, it would be nice if the "default mode" was to use the file mode of the copied file, rather than a generic 0644. This is particularly important when copying startup shell scripts. I generate these in gradle, which is nice because I can keep the jar versions in the shell script in sync with the gradle dependencies, but then I have to do a manual "chmod a+x bin/*" every time they are regenerated. Currently the files end up with 0644 even though the original file is 0755 and the copySpec has fileMode=0755.