Bug #15244 explains why it's pretty hard to read symlinks from the filesystem. However, it occurred to me that there's no reason why the <tar> task couldn't be told explicitly what symlinks to create and include them in the archive. The advantage with this approach is that I could run the build script on Windows (which doesn't support symlinks in the Unix sense) and still generate a .tar archive that could be extracted on Linux with the proper symlinks. I'm proposing the creation of a nested <symlink> element that provides the name and target (and perhaps other attributes) for the symlink. The <tar> task would read the element and generate a symlink within the .tar archive. At no point would there need to be a symlink on the actual filesystem itself. For example, this would create a symlink called "link" (in the root directory) with a relative path pointing to the file "foo/bar/target": <tar destfile="archive.tar"> <tarfileset dir="somedir"> <include name="foo/bar/target"/> </tarfileset> <symlink name="link" target="foo/bar/target"/> </tar> Another option might be to have the <symlink> element under the <tarfileset> element so that it can inherit settings like user, group and permissions.
*** Bug 43689 has been marked as a duplicate of this bug. ***
I also a similar functionality: I want to create a Mac-specific .tar.gz bundle which should contain the application's .app directory structure containing a PDF-documentation file, but the documentation should also be accessible parallel to the .app directory structure, so the average user is able to view the documentation after unpacking the .tar.gz file (note: the .app directory structure on OS X usually is treated as file by the Finder). When we can expect this issue to be fixed? Currently, I don't know of a work-around, except of duplicating the .pdf file in both locations.
Mike, nobody works on Ant in any paid form, the general rule is that to fix a problem that you have, the best way is to patch your local copy of the source, then submit a patch including those changes and some tests/documentation, as that is what is needed to get your patch in the main branch, There is a workaround, which is you create the (hanging) symlink in the source filesystem pointing to the final destination, and then tar it using the native tar command, instead of the <tar> task. I've been using this when creating RPMs. It isn't x-platform though, only works on a unix system.
(In reply to comment #3) > There is a workaround, which is you create the (hanging) symlink in the source > filesystem pointing to the final destination, and then tar it using the native > tar command, instead of the <tar> task. I've been using this when creating > RPMs. It isn't x-platform though, only works on a unix system. This is no work-around for us, because we work on Windows. If I would have the experience of how the tar format looks like, I've already would have done the change myself and maybe suggested a patch. Unfortunately, I haven't that experience.