I'm running into a strange situation with the maven-resources-plugin. I have my test resources set up normally, like this:
<testResources> <testResource> <directory>src/test/resources</directory> </testResource> </testResources> …so basically the defaults made explicit. Today I suddenly noticed that—Maven 3.5.0, Maven Resources Plugin 3.0.2—although the plugin is reporting that (a) filtering is off and (b) there are 26 files to copy, none of them is actually copied. I dug in further and found that (ultimately) the culprit is here: https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/FileUtils.java#L1960 Briefly, each of the files that the plugin has decided to copy has a lastModified() of 0L, which means that in the absence of an overwrite being specified none of them is copied. Hmm, that's odd. It turns out the files in question that I'm working with happen to have been extracted from a tar archive, and have modification times of, for example, December 31, 1969. (They aren't that old; that's obviously something wonky about how they were wrapped up in the tar archive.) Obviously that's before the 1970 epoch, so I'm guessing that java.io.File#lastModified() probably returns something like Math.max(0L, realModificationTime) (the documentation says it returns 0L in the case of an error, but I don't think this is an error case). Is this expected behavior of the FileUtils class? There is documentation that indicates the lastModified() check was chosen explicitly ( https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/FileUtils.java#L1908-L1909). I can work around the issue, I guess, by touching all the files in an extra automated step or moving this to an explicit maven-resources-plugin:resources invocation with overwrite specified, but it seems to me this should Just Work™. Thanks, Best, Laird