You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Laird Nelson <lj...@gmail.com> on 2017/07/03 16:55:36 UTC
Maven resources plugin issue?
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
Re: Maven resources plugin issue?
Posted by Laird Nelson <lj...@gmail.com>.
On Mon, Jul 3, 2017 at 10:10 AM Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> On 03/07/17 18:55, Laird Nelson wrote:
> > 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.
>
> The above snippet does not turn on filtering. Do I mistaken something?
>
No, I meant simply to stress that everything is simple. Everything is set
to defaults.
> What do you mean by it's not copied?
>
My src/test/resources hierarchy has 26 files. None of them show up in
target/test-classes anywhere.
Can you please create a complete example project which shows the
> problem?...best would be on github so we can take a look...
>
As I have time; yes. In the meantime, simply create files under
src/test/resources and mark their modification times as being December 31,
1969. Then see if they are copied. They will not be. They should be
(IMHO).
Best,
Laird
Re: Maven resources plugin issue?
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 03/07/17 18:55, Laird Nelson wrote:
> 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.
Why? Maven is about Convention over Configuration...so just remove it
cause it's default...
>
> 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.
The above snippet does not turn on filtering. Do I mistaken something?
What do you mean by it's not copied?
Can you please create a complete example project which shows the
problem?...best would be on github so we can take a look...
Before we dig into details I would like to have the start situation
define...
Kind regards
Karl Heinz Marbaise
>
> 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™.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org