On 12/09/2013, at 12:25 AM, Harald Schmitt <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>> 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>> 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>> 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? -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle eXchange 2013, Oct 28th in London, UK: http://skillsmatter.com/event/java-jee/gradle-exchange-2013
