Am 09.08.2013 04:21, schrieb Adam Murdoch:
>
> On 05/08/2013, at 9:20 PM, Harald Schmitt <li...@hschmitt.de
> <mailto: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.
I got a first smell when writing the tests for untar and when I coded
the tar support your suggestion became pretty obvious, but I was not
sure whether I should touch the API. I just added a "isSymbolicLink" to
FileTreeElement
https://github.com/surfing/gradle/tree/tar-rc-1
>
> 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.
When writing the tar support I added a "symboliclink" to the
TestWorkspaceBuilder.groovy to have the TestFile DSL support symbolic
links. So yes this makes much sense.
https://github.com/surfing/gradle/tree/tar-rc-1
>
> 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.
A strategy would be good thing here something like FAIL, INLINE, SKIP so
when you convert a tar to a zip you can decide what happens to symbolic
links.
>
> 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.
Just and observation here. Copying a symbolic link fails at the moment
if the link is copied before the target but I think that will resolve
automatically.
>
> 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.
Yes, I will help here. The tar/untar implementation is the smallest part
on it and it is already done. But I can take another piece, too.
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
