[ 
https://issues.apache.org/jira/browse/MSHARED-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095970#comment-17095970
 ] 

Robert James Oxspring commented on MSHARED-884:
-----------------------------------------------

I’m not clear what aspect of that 4kloc file is supposed to help here. Can you 
point to something more specific?
Approaches tracking the available properties for substitution must always fail 
since the likes of maven.build.timestamp will always be different. I don’t see 
how tracking the used properties is possible without at least the io of an 
extra read of the source file, to identify the properties that count. The java 
doc fix mojo doesn’t appear to address this does it?

(Happy to take the conversation back to the dev list if preferred)

> Only overwrite filtered resources when contents differ
> ------------------------------------------------------
>
>                 Key: MSHARED-884
>                 URL: https://issues.apache.org/jira/browse/MSHARED-884
>             Project: Maven Shared Components
>          Issue Type: Improvement
>          Components: maven-filtering
>            Reporter: Robert James Oxspring
>            Priority: Major
>
> When filtering files with the {{MavenFileFilter.copyFile}} method, the 
> destination file should only be overwritten if the contents have changed. 
> Currently we unconditionally overwrite the contents in this situation, 
> potentially leading to unnecessary downstream work. When the {{overwrite}} 
> parameter is {{true}} then overwriting should overwrite as it does now.
> Given a {{copyFile}} call
>  When an identical {{copyFile}} operation is performed
>  Then the destination file should remain unmodified
> Given a {{copyFile}} call with {{overwrite}} set {{true}}
>  When an identical {{copyFile}} operation is performed
>  Then the destination file should be overwritten
> The [linked pull request|https://github.com/apache/maven-filtering/pull/5] 
> meets these requirements by writing the filtered resource to a temporary file 
> and then comparing the temporary contents to the content of a previously 
> written target file. If the contents match then the temporary file is 
> deleted, otherwise it's renamed over the top of the target file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to