[
http://jira.codehaus.org/browse/MSHARED-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin SB closed MSHARED-136.
-----------------------------
Resolution: Fixed
I'm closing this as I think I was wrong here. I was looking at the wrong
overload for FileUtils.copyFile; the overload that is used should be doing the
checking based on file timestamps. I'm going to have to track down my issue,
but it looks like the filtering code is doing the right thing.
> Filtering should not update unchanged files
> -------------------------------------------
>
> Key: MSHARED-136
> URL: http://jira.codehaus.org/browse/MSHARED-136
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
> Reporter: Justin SB
>
> While tracking down why maven rebuilds projects where nothing has changed, I
> believe that one of the causes is that the resources:copy task copies
> resources even when the files in the target dir are identical. The
> resources:copy task uses the shared maven-filtering component, which itself
> uses org.codehaus.plexus.util.FileUtils.copyFile.
> While ideally this could be fixed in FileUtils.copyFile, changing that
> function is more likely to break other things, so I think the fix has to be
> done in maven-filtering. (I don't believe it can be done in the resources
> plugin, because that deals in directories, not individual files)
> I propose that in DefaultMavenFileFilter, in the case where no filter is
> used, before the call to FileUtils.copyFile, a call to
> FileUtils.contentEquals is made first. If the contents are equals, there's
> no need to copy the file. (FileUtils.copyFile doesn't copy metadata anyway,
> so contentEquals is the only test we need)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
