But if you're in the mood for committing, I have something for you - you could merge this patch onto the branch - it's getting late here and I would like to go home and get something to eat.... :o)
As for the linefeeds, I think the correct solution is to fix up the line feeds for the tars and not the zips using Ant's <FixCRLF> task. I believe that for shell-emulation environments on Windows that the linefeeds should still be CRLF, not LF, but could somebody confirm that?
I disagree, that would push the problem to everyone building on one platform and deploying on multiple, for all releases from now and forever. Any decent shell-emulation environment must IMHO take into account that shell scripts are LF terminated (at least cygwin does). Just as any emulator running .bat files on a unix would have to deal with CRLF.
ok, since I don't use Cygwin much, so I didn't know what its behavior would be.
For the record, you could still build on any platform and get identical results using <FixCRLF>, and in fact might be useful for guaranteeing that the line feeds are correct. The task allows you to specify what the linefeeds in a file should be, regardless of the current platform's eol-style, not just fix them up to the current platform. So, as an example, I believe .subversion/config overrides properties in the repostiory, so if someone had svn:eol-style native for .sh and .bat in their .subversion/config, as is currently recommended by http://www.apache.org/dev/svn-eol-style.txt
, then .bats and .shs would end up being LF on Linux. We could guarantee that each file has the correct line feeds by running them through the <FixCRLF> task in the release target before archiving.
A better question is what does Ant's tar on Windows do with the executable bit? NT and NTFS don't have one, so what does it do on Windows? We might need to specify the exact expected permissions in those files' <tarfileset> in the release targets.
I'm actually sort of surprised no one has brought this up before.