Bug 62379 - copy task with resourcelist flattens directories
Summary: copy task with resourcelist flattens directories
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.10.3
Hardware: PC All
: P2 normal (vote)
Target Milestone: 1.10.4
Assignee: Ant Notifications List
Depends on:
Reported: 2018-05-16 11:43 UTC by yoerg
Modified: 2018-05-22 06:08 UTC (History)
0 users

The sample project directory including the build file (530 bytes, application/x-gzip)
2018-05-16 11:43 UTC, yoerg

Note You need to log in before you can comment on or make changes to this bug.
Description yoerg 2018-05-16 11:43:37 UTC
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):


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:


Here is a minimal build file:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>

      <!-- Simply defined here,
           actually read from a propertyfile -->
      <property name="inputFiles">source/file-one

      <copy todir="dest">
          <propertyresource name="inputFiles" />


However, this results in the following directory:


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:


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.
Comment 1 Stefan Bodewig 2018-05-20 14:55:25 UTC
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.
Comment 2 Stefan Bodewig 2018-05-20 15:33:19 UTC
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.
Comment 3 Stefan Bodewig 2018-05-20 17:55:07 UTC
I've added both "fixes" that I discussed before to the branches that will lead to 1.10.4 and 1.9.12.
Comment 4 yoerg 2018-05-22 06:08:40 UTC
Great to hear that fixes are on the way. Thanks you!

Until then I will use <includesfile> with 8859 encoding.