Am 12.09.2013 12:24, schrieb Adam Murdoch: > > On 12/09/2013, at 12:25 AM, Harald Schmitt <li...@hschmitt.de > <mailto:li...@hschmitt.de>> wrote: > >> Am 20.08.2013 01:47, schrieb Adam Murdoch: >>> >>> On 15/08/2013, at 7:39 PM, Harald Schmitt <li...@hschmitt.de >>> <mailto:li...@hschmitt.de> >>> <mailto:li...@hschmitt.de>> wrote: >>> >>>> Am 09.08.2013 03:53, schrieb Adam Murdoch: >>>>> >>>>> On 08/08/2013, at 12:01 AM, Harald Schmitt <li...@hschmitt.de >>>>> <mailto:li...@hschmitt.de> >>>>> <mailto:li...@hschmitt.de> >>>>> <mailto:li...@hschmitt.de>> wrote: >>>>> >>>>>> Am 06.08.2013 01:20, schrieb Adam Murdoch: >>>>>>> >>>>>>> On 05/08/2013, at 9:20 PM, Harald Schmitt <li...@hschmitt.de >>>>>>> <mailto:li...@hschmitt.de> >>>>>>> <mailto:li...@hschmitt.de> >>>>>>> <mailto: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 >>>>>>>> For the other way round, I realized that there are some bits >>>>>>>> missing, to >>>>>>>> implement support for symbolic links with the Tar task type. >>>>>>>> The interface Symlink >>>>>>>> https://github.com/gradle/gradle/blob/master/subprojects/native/src/main/java/org/gradle/internal/nativeplatform/filesystem/Symlink.java >>>>>>>> needs two more functions >>>>>>>> public boolean isSymlink(File linkCandidate); >>>>>>>> public RelativePath symlinkTarget(File link); >>>>>>>> >>>>>>>> Determining whether it is a symbolic link could be achieved with >>>>>>>> pure >>>>>>>> java code as the ANT class SymbolicLinkUtils does it, but it >>>>>>>> could be >>>>>>>> much faster using native tools. >>>>>>>> But to query the target relative path , I don't know whether this >>>>>>>> can be >>>>>>>> done in java? >>>>>>>> >>>>>>>> I'd need someone to implement the native part. Is there someone >>>>>>>> willing? >>>>>>>> Is this something that will go into gradle? >>>>>>> >>>>>>> The native toolkit that we use >>>>>>> (https://github.com/adammurdoch/native-platform) already has some >>>>>>> support for symlinks. It's missing a method to detect if a file is a >>>>>>> symlink, but I can add that. It might take me a few days to get it >>>>>>> done, >>>>>>> though. >>>>>>> >>>>>>> We can also use the Java 7 file attributes stuff to determine if >>>>>>> a file >>>>>>> is a symbolic link. There's also the trick where we can use >>>>>>> File.getCanonicalFile() to determine if something is a symlink or >>>>>>> not. >>>>>>> >>>>>>> What you could do to get started is to add the methods that you >>>>>>> need on >>>>>>> Symlink with dummy implementations or implementations that only >>>>>>> work on >>>>>>> Java 7 or that use the Ant stuff for now. Then you can continue >>>>>>> on with >>>>>>> the Tar stuff while I add the native support in the native >>>>>>> toolkit and >>>>>>> wire it in. >>>>>> The native toolkit you are referring is not used for symlinks in >>>>>> gradle >>>>>> at the moment, but it makes sense to switch to it. >>>>> >>>>> We're slowly moving from jna/jna-posix to native-platform, and the plan >>>>> is to switch the Symlink implementation over. >>>> I took a look into NativeServices class and FileSystem class. Is the >>>> plan to provide the FileSystem service from NativeServices? >>>> Because there is a problem with FileSystems.getDefault() which would >>>> introduce a package cycle if it uses NativeServices. >>> >>> Right. We're going to have to shuffle some things around to make it work. >> Can you give me the direction how this should be done? >> FileSystems.getDefault() could be deprecated and use the old code >> and NativeServices returns a different FileSystem implementation with >> native-platform ? > > I wouldn't bother too much with this at the moment. It's fine if this > just works with Java 7 to start with. > > Instead, I think we should make some deeper changes in the > FileTree/CopySpec area to support symlinks. I've written up a spec, > broken up into a few steps, or stories, as part of the broader plan for > copying. > > The first story is here: > https://github.com/gradle/gradle/blob/master/design-docs/copy-spec-improvements.md#story-allow-symbolic-link-traversal-strategy-to-be-declared-for-a-file-tree > > And continues on for a few more after that. > > Would you be interested in tackling some of this? Sure, I will start with the first one. I think it is doable for me. And then we will see how it continues.
Meanwhile I already have an investigation for you. It is related to the untar story: https://github.com/gradle/gradle/blob/master/design-docs/copy-spec-improvements.md#story-expose-symbolic-links-in-tar-file-trees I already investigated a problem with my first naiv implementation. When the symbolic link is visited before its target or the target does not exist you cannot distinguish those situations at that moment. Do you think that problem can occur with copying, too? --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
