[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359189#comment-359189
]
Kristian Rosenvold commented on MSHARED-394:
--------------------------------------------
You make a compelling argument for a combined solution and basically use
content-based copying/filtering for the velocity templates. If you want to have
a shot at changing *just* the Velocity generation to use such an algorithm I'll
happily review this; I want to do the interpolation stuff as a christmas hack
:) If you you switch to using MavenReaderFilter instead of MavenFileFilter you
should be able to solve such an issue entirely within resources-plugin. Take a
look at ReaderFormatter.java in assembly plugin for inspiration.
DeferredFileOutputStream from commons-io would probably be a nice thing to use
so you can keep the transformed output in memory until it reaches a given
maxsize. I seem to remember we also use that in assembly :) If we need to move
bits of your change elsewhere later we can look at this when you finish :)
I'm still pondering this a bit. One one hand we have a fixed set of templates
that have known interpolation requirements. Rather than solving the general
problem of "any" Velocity inteprolation, we could just solve the *specific*
problem of interpolating the few specific ones we know to be used and delegate
the "generic" problem elsewhere. So we might still be able to go for some kind
of combined strategy.... (Thinking thinking...)
> 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
> Assignee: Kristian Rosenvold
>
> 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)
