On 2018-06-06, Gintautas Grigelionis wrote: > 2018-06-06 14:31 GMT+02:00 Stefan Bodewig <bode...@apache.org>:
>> I guess here our API breaks down as we only ever deal with files or >> directories (outside of the symlink task). > FileSet documentation should be more explicit about the matter, in > particular explaining what "followsymlinks" really means. You are right. In a Java world where you couldn't really do anything with symlinks it has probably been clear implicitly. >> Would the symlink be included in DirectoryScanner's "included files" or >> "included directories"? What will <copy> do to a symlink that is >> included but not followed. > "Files or directories" dichotomy might be a straitjacket, but symlinks can > be fitted into it depending on what their target is. DirectoryScanner's interface provides you with files and directories and as it stands these File objects may actually by symlinks and the implicit expectation is that whoever uses them follows the links and in the end works on the target. We could add new array of symlinks that are not supposed to be followed but most tasks would simply ignore them (all tasks that we don't change ourselves). > Dangling symlinks should go into notFollowedSymlinks. Regarding > <copy>, included but not followed symlink must be left as is (eg > directories are not filtered either). Probably. There will not be a interpretation that will work for all tasks, it will be on a task by task basis. As we can only control the tasks that are inside of Ant's codebase, this means we must not change the interpretation of the files and directories returned by DirectoryScanner at all. > I wonder if we can have an interim solution when selectors could use > proper followsymlinks semantics, but behaviour of DirectoryScanner is > unchanged? You may give it a try, I'm not sure exactly what you mean. >>> Consequently, I expect >>> followsymlinks="false" skipsymlinks="false" to behave as >>> followsymlinks="false"; >> which would be the same as skipsymlinks="true", right? > No, under the new proposal that would include the symlinks as symlinks, not > files or directories. Where would DirectoryScanner put those included symlinks? > in the meantime, would it make sense to document what "followsymlinks" > means in FileSet and what "followsymlinks" means in selectors that > permit the attribute? We must document that, I'd say :-) > There are other issues, like support for symlinks in archives (JRE does not > support them in > zip files [1], rather one -- like Gradle [2] -- must use Commons Compress). > Actually, there are a couple > of old Bugzilla issues addressing symlinks [3, 4] :-). I know Commons Compress pretty well ;-) and it doesn't really support symlinks in archives either. Given that Ant's zip package is the parent of Compress' zip support we should be able to do whatever Commons Compress can do here as well. There is a good reason why we don't use java.util.zip at all. > So, what's the plan? It's your itch, what is your plan? :-) Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
