It appears as though Apache Ant doesn't play nice with Mac OS X *.app launcher directories.

I'm copying the Eclipse RCP *.app launcher directory with my AudioMan Ant packaging script to build the Mac OS X Carbon versions of AudioMan2 and the Durham Quick Editor. I'm just using the <copy> task, like this:

<target name="copy-rcp-launcher">
   <mkdir dir="${packager.package.dir}"/>
   <copy todir="${packager.package.dir}">
      <fileset dir="${rcp.project.dir}/_
platform-launcher-3.0.2/bin/${packager.os}/${packager.ws}"/>
      <fileset file="${rcp.project.dir}/_
platform-launcher-3.0.2/startup.jar"/>
   </copy>
</target>

**NOTE: I had to put a _ line continuation in that long line. It's not in the original code.

The packager generates a completely assembled RCP application for the platform in the ${packager.package.dir} directory and then ZIPs that directory up for distribution. The ${packager.package.dir} directory should be runnable after it is assembled and this works fine in Windows (with eclipse.exe).

In Mac OS X I click on the launcher in the assembled RCP application's directory and nothing happens. The workspace\ directory is not created. The configuration\ directory is not changed. The Eclipse *.app launcher is broken somehow but it is exactly the same size as the directory it was copied from.

If I delete the launcher that my Ant packaging script copied and use the Finder to copy over a fresh launcher from the RCP binary *.tar.gz file, the application works! Very odd. Ant is copying the launcher *.app directory incorrectly somehow ... but how?

Update 10:50 AM: Ant <copy> Removes Permissions!

Eclipse.app is a directory -- you can see its contents if you open a Terminal and cd into it. The file Eclipse.app\Contents\Info.plist lists a file named eclipse as the CFBundleExecutable, which probably means that Mac OS X expects this file to have executable permissions.

If you look in Eclipse.app\Contents\MacOS\ you'll notice that there are indeed two files with -rwxr-xr-x executable permissions: eclipse and java_swt.

I guess this is why Eclipse for Mac OS X comes in a gzip'd tar file instead of a ZIP file. ZIP archives do not preserve file permissions and tar archives do. Why are the Linux Eclipse builds ZIP'd then? I guess they expect Linux users to be able to chmod their own eclipse executable -- especially since it isn't burried in a launcher like it is on the Mac.

Anyway, at the bottom of Ant's documentation for the <copy> task they note that Unix file permissions are NOT preserved by the <copy> task. D'oh!

Ant <copy> is breaking the launcher because it reduces the file permissions of the two executables to -rw-r--r--. I'll have to figure out how to solve this problem without introducing too much platform-specific code in my Ant build scripts.

My build machine is on a Linux box so that probably helps things -- I can set permissions before I build the distributable (I'll also have to verify permissions aren't modified by CVS -- Update 11:40 AM: CVS preserves permissions). But it looks like my Mac OS X distributable will have to be a *.tar.gz file until I figure out how to make a nice self-contained Mac package.

While I'm at it I should make my Linux distributables gzip'd and tar'd as well until I figure out how to make something more friendly like an RPM. Linux users don't need their hand held but they'd probably rather not have to chmod anything.

I'd like the AudioMan products to just work right out of the box on every platform. I don't want to lose a user because the install is a PITA.

Many thanks to my anonymous commenter for the solid lead.