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
