[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359172#comment-359172
]
Vladimir Sitnikov edited comment on MSHARED-394 at 12/16/14 2:34 PM:
---------------------------------------------------------------------
This is non-trivial.
0) My main concern is Velocity templates. org.apache:apache pom uses Velocity
templates to render {{DEPENDENCIES}}, etc.
1) Regular property-only interpolations are important as well, however it does
not make much sense if we cover just the basic stuff.
2) In Velocity, I expect the following expressions are very hard to tame:
{{#include("one.gif","two.txt","three.htm")}}, {{#evaluate}}, {{#define}}
3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you
can identify "the required bits". If you try to hash the whole {{MavenProject}}
thing, I expect the cache will always miss.
Do you still think this kind of coupling between filtering and Velocity is
worth doing?
was (Author: vladimirsitnikov):
This is non-trivial.
0) My main concern is Velocity templates. org.apache:apache pom uses Velocity
templates to render {{DEPENDENCIES}}, etc.
1) Regular property-only interpolations are important as well, however I does
not make much sense if we cover just the basic stuff.
2) In Velocity, I expect the following expressions are very hard to tame:
{{#include("one.gif","two.txt","three.htm")}}, {{#evaluate}}, {{#define}}
3) {{MavenProject}} is passed to the {{VelocityContext}}. I am not sure if you
can identify "the required bits". If you try to hash the whole {{MavenProject}}
thing, I expect the cache will always miss.
Do you still think this kind of coupling between filtering and Velocity is
worth doing?
> 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)
