[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359118#comment-359118
]
Kristian Rosenvold edited comment on MSHARED-394 at 12/15/14 1:41 PM:
----------------------------------------------------------------------
I will need to think a little more about this problem. I dislike a
comparison-based solution and would really try to come up with something
better.
Please note that we currently do not compare content byte-for-byte like you
suggest, but we have gotten amazingly much better at preserving file
attributes, so much that this has also become a problem the other way around.
The code in question is
org.apache.maven.plugin.assembly.format.ReaderFormatter#createReaderFilter
which uses a MavenReaderFilter instead of a MavenFileFilter. The reader filter
can be injected into plexus io as can be seen at
org.apache.maven.plugin.assembly.archive.phase.FileItemAssemblyPhase#execute
and various other places. But this code alone is by far not enough pieces to do
what you want to do.
Personally I'm not interested in accepting "quick fixes", so I'd like any
solution to be the best we can do at the moment. this may turn out to be your
proposal - but hopefully there's something even better to be found...
was (Author: krosenvold):
I will need to think a little more about this problem. I dislike a
comparison-based solution and would really try to come up with something
better.
Please note that we currently do not compare content byte-for-byte like you
suggest, but we have gotten amazingly much better at preserving file
attributes, so much that this has also become a problem the other way around.
The code in question is
org.apache.maven.plugin.assembly.format.ReaderFormatter#createReaderFilter
which uses a MavenReaderFilter instead of a MavenFileFilter. The reader filter
can be injected into plexus io as can be seen at
org.apache.maven.plugin.assembly.archive.phase.FileItemAssemblyPhase#execute
and various other places.
Personally I'm not interested in accepting "quick fixes", so I'd like any
solution to be the best we can do at the moment. this may turn out to be your
proposal - but hopefully there's something even better to be found...
> Avoid rewrite of destination in DefaultMavenFileFilter#filterFile when
> producing the same contents
> --------------------------------------------------------------------------------------------------
>
> Key: MSHARED-394
> URL: https://jira.codehaus.org/browse/MSHARED-394
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
> Affects Versions: maven-filtering-1.2
> Reporter: Vladimir Sitnikov
>
> See relevant MRESOURCES-168.
> When processing "filtered" resources, maven-filtering always overwrites
> destination files, leading to rebuild of the upstream results (e.g. jar file
> being repackaged due to "DEBUG] isUp2date: false (Resource with newer
> modification date found.)").
> I think maven-filtering can do better job here: it can double-check if the
> resource contents after filtering is equal to the contents of the existing
> file, then it should avoid overwrite of the destination file.
> The change would be localized in
> {{org.apache.maven.shared.filtering.DefaultMavenFileFilter#filterFile}}:
> {code:java}
> private void filterFile(@Nonnull File from, @Nonnull File to, @Nullable
> String encoding, @Nullable List<FilterWrapper> wrappers) throws IOException,
> MavenFilteringException {
> if(wrappers != null && wrappers.size() > 0) {
> Reader fileReader = null;
> Writer fileWriter = null;
> try {
> fileReader = this.getFileReader(encoding, from);
> fileWriter = this.getFileWriter(encoding, to); // Here
> temporary buffer should be used to avoid accidental file overwrite
> Reader src = this.readerFilter.filter(fileReader, true,
> wrappers);
> IOUtil.copy(src, fileWriter);
> } finally {
> IOUtil.close(fileReader);
> IOUtil.close(fileWriter);
> }
> } else if(to.lastModified() < from.lastModified()) {
> FileUtils.copyFile(from, to);
> }
> }{code}
> The change would require to buffer the contents in memory, thus it might lead
> to OutOfMemory errors. I suggest disabling this buffering if the size of the
> source file exceeds some threshold.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
