Adam Murdoch wrote:
Hi,
Would you expect the following to pass?
given:
file("a/b.txt") << "\$foo"
when:
buildScript """
task c(type: Copy) {
from("a") {
filesMatching("b.txt") {
expand foo: "bar"
}
into "nested"
}
into "out"
}
"""
then:
succeeds "c"
and:
file("out/nested/b.txt").text == "bar"
It doesn't. It turns out that filesMatching matches the relative
destination path, so it needs to be filesMatching("nested/b.txt"). I
find this a little surprising.
It seems like it would be more predictable to use the relative path
to the file from the nearest 'from' statement. What's the rationale
for the current behaviour?
It’s just a bug, I would think. The pattern should be relative to the
source path, not the destination path. An interesting question is what
to do with those files whose name is transformed in some way (eg
using rename()) - is the pattern applied before or after transformation?
Looks like we explicitly wanted post rename:
https://github.com/gradle/gradle/blob/master/subprojects/core/src/integTest/groovy/org/gradle/api/tasks/CopyTaskIntegrationTest.groovy#L490
I think this is the wrong way to go. I can see that in some cases it is
useful, but I find it far harder to reason about than just applying to
the source path. Using the source location seems less surprising to me too.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
