Created attachment 35937 [details] The sample project directory including the build file Trying to copy a list of files with resourcelist copies all files directly into the destination directory, throwing away subdirectories. If have a project directory structure like this (as attached): build.xml source/file-one source/file-two source/subdirectory/file-three A program returns a newline-separated list of some of these files, e.g. 'source/file-one' and 'source/subdirectory/file-three'. Now I would like to copy that selection to another directory 'dest'. I would expect the following directory structure as a result: dest/source/file-one dest/source/subdirectory/file-three Here is a minimal build file: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <project> <!-- Simply defined here, actually read from a propertyfile --> <property name="inputFiles">source/file-one source/subdirectory/file-three</property> <copy todir="dest"> <resourcelist> <propertyresource name="inputFiles" /> </resourcelist> </copy> </project> However, this results in the following directory: dest/file-one dest/file-three I don't find this behavior mentioned anywhere in the documentation. The behaviour is the same in Ant 1.9.11 and 1.10.3. In Ant 1.8.4, the resulting directory structure is: dest/<basedir>/source/file-one dest/<basedir>/source/subdirectory/file-three Some background: Since the actual file names in my project may contain spaces, I can't use fileset with include. Using includefiles works as long as the file names don't contain unicode characters (which they may unfortunately). But I can't convince includefiles to see the input file as anything other than ISO-8859-1.
I fully agree with you this is not the expected behavior (and neither is the behavior of 1.8.4), am looking into it. But I think you should be able to use nested include elements as their name attribute doesn't split anything, so names with spaces are fine. The includesfile is read using the platforms default encoding which seems to be ISO-8859-1 for you. I think we should add an encoding attribute to the includesfile nested element for situations like yours.
OK, the problem is a bit deeper than that. <resourcelist> doesn't have a concept of a basedir, so when I use absolute file names in the lines passed to the <resourcelist>, <copy> cannot know what directory the names shall be relative to - and it picks the file's parent directory as the virtual basedir which leads to a behavior similar to the one you see. In your case you provide relative file names as lines to <resourcelist> but those get resolved relative to the project's basedir inside of <resourcelist> and so end up being absolute file names as well. There is no easy way to "fix" this is <copy> cannot know what else might be the proper basedir. In your case you'd want ${basedir}/source which is something <copy> will never be able to come up with on its own. I see you are constructing the list of files based on a property, so using multiple nested <include> elements probably is not an option because they'd have to be hard coded. A workaround I see is writing the property to a file and ensure the output encoding is ISO-8859-1. This might work as a workaround for you. For the next versions of Ant I intend to add a basedir attribute to <resourcelist> so the FileResources created know their baseidr - and add an encouding attribute to the includesfile element.
I've added both "fixes" that I discussed before to the branches that will lead to 1.10.4 and 1.9.12.
Great to hear that fixes are on the way. Thanks you! Until then I will use <includesfile> with 8859 encoding.