Symbolic link support

I do a lot of work with zip files that contain symbolic links (think ios/maosx frameworks). Gradle sadly doesn’t support symbolic links, so I’ve had to have gradle execute a shell to run zip/unzip from the command-line.

Needing to use the command-line for this is quite a pain, as it requires a user to have zip/unzip already installed (which is a particular problem on Windows).

It would be great if Gradle supported this. To see how hard it would be, I’ve made a “symzip” plugin that adds java-based support for symlinks:

It’s largely based on the Zip task code found in Gradle. If people find this useful, perhaps it could find its way into Gradle proper.

1 Like

Thanks Aaron for sharing! At one point we find the time to make the
symlink support better in Gradle. If you’re interested in helping us
here you can start a discussion about this at the gradle dev mailinglist
and/or provide a pull request.

I’m also interested in getting the symlink support improved, specifically on Windows (Vista and above). When I was looking at the Git history of I noticed this commit by @eljobe saying “We really don’t want to create symlinks even when it is technically supported by the operating system”. Unfortunately, the commit message does not give any rationale why this decision was made. Mind sharing any insight on that?

1 Like

This has caused me a lot of grief lately. I have a 3rd party native library that uses symlinks to alias libs like --> --> If I use gradle’s built-in Copy/Tar or tarTree it either duplicates the files on copy or tarring, or it creates 0 length files on untarring an archive with preserved symlinks. All of these tasks have to be replaced by arcane Exec tasks.