On 05/08/2013, at 9:20 PM, Harald Schmitt <li...@hschmitt.de> wrote:
> Hi, > > I did a first try to support symbolic links when using tarTree() for untar. > https://github.com/gradle/gradle/pull/182 I think we want a somewhat deeper solution. By 'deeper' I mean that I think it would be worthwhile to make symbolic links a first-class concept in the file infrastructure. Currently, FileTree and CopySpec produce 2 types of elements: A file and a directory. We should add a symbolic link element type as well, as a symbolic link is neither a file nor a directory. It's just an element that refers to some other element. To do this, we'd add some subtypes for FileTreeElement to represent files, directories and symbolic links, and change the TarFileTree and DirectoryFileTree implementations to use these. The second part to the solution is to change the things that copy the elements so that they understand symbolic links. TarCopyAction and FileCopyAction both be changed to handle symbolic links. The other actions can fail when a symbolic link is used as input, or possibly could inline the target. To round it out, we should add some methods similar to CopySpec.eachFile { } which can handle other types of elements, including symbolic links. Possibly an eachElement { } method, and an eachDirectory { } and eachLink { } method too. Probably some equivalents on FileTree, too. What do you think? If you're interested in helping with this, I can flesh out the details in a spec and we can chop it up into a few pieces. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
