[
https://jira.codehaus.org/browse/MSHARED-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=359090#comment-359090
]
Vladimir Sitnikov edited comment on MSHARED-394 at 12/15/14 4:20 AM:
---------------------------------------------------------------------
{quote}This feature is currently only implemented in assembly-plugin but
"someone" might want to take a look at migrating this to other plugins.{quote}
Can you please pin-point the API?
I still see no good reason why say "maven-assembly-plugin" should double-check
the contents of resource "just in case the contents is equal".
Well, there might be ill-behaving plugins (including external to maven) that
regenerate files for no reason, however, it is still an overhead to
maven-assembly when it has to recheck the contents.
It would be better if well-known maven-resource-plugin would not regenerate the
file in the first place.
It turns out, maven-resources-plugin relies on maven-filtering, thus there is
nothing to fix in maven-resource-plugin itself.
Here's real life scenario:
Apache recommends the following parent.pom:
{code:xml} <parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>14</version>
</parent>{code}
This pom defines maven-resources-plugin that creates {{DEPENDENCIES, LICENSE,
NOTICE}} files.
Due to "filtered files are always rewritten bug", maven-jar-plugin always
rebuilds the jar.
This takes noticeable time and this impacts lots of projects that inherit this
pom. It impacts other projects that use filtered resources as well.
The net effect is "maven is slow, just use gradle".
{quote}This feature is currently only implemented in assembly-plugin but
"someone" might want to take a look at migrating this to other plugins.{quote}
Please clarify if you consider updating {{DefaultMavenFileFilter#filterFile}} a
valid option.
I guess I can figure out some pull request, however before I start the work I
need to know if it has chances being committed.
>From my point of view,
1) If maven-filtering must not be changed it would complicate client code with
no significant reason
2) Updated {{filterFile}} would improve build times for all current plugin
versions, while update of each "client" plugin would take a while
3) While having this feature implemented at different levels (in both
maven-filtering, maven-jar, maven-assembly, etc) helps to cover more cases, I
would suggest still cover the very basic case in maven-filtering as a quick-win.
was (Author: vladimirsitnikov):
{quote}This feature is currently only implemented in assembly-plugin but
"someone" might want to take a look at migrating this to other plugins.{quote}
Can you please pin-point the API?
I still see no good reason why say "maven-assembly-plugin" should double-check
the contents of resource "just in case the contents is equal".
Well, there might be ill-behaving plugins (including external to maven) that
regenerate files for no reason, however, it is still an overhead to
maven-assembly when it has to recheck the contents.
It would be better if well-known maven-resource-plugin would not regenerate the
file in the first place.
It turns out, maven-resources-plugin relies on maven-filtering, thus there is
nothing to fix in maven-resource-plugin itself.
Here's real life scenario:
Apache recommends the following parent.pom:
{code:xml} <parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>14</version>
</parent>{code}
This pom defines maven-resources-plugin that creates {{DEPENDENCIES, LICENSE,
NOTICE}} files.
Due to "filtered files are always rewritten bug", maven-jar-plugin always
rebuilds the jar.
This takes noticeable time and this impacts lots of projects that inherit this
pom. It impacts other projects that use filtered resources as well.
The net effect is "maven is slow, just use gradle".
{quote}This feature is currently only implemented in assembly-plugin but
"someone" might want to take a look at migrating this to other plugins.{quote}
Please clarify if you consider updating {{DefaultMavenFileFilter#filterFile}} a
valid option.
I guess I can figure out some pull request, however before starting the work I
need to know if it has changes being committed.
>From my point of view,
1) If maven-filtering must not be changed it would complicate client code with
no significant reason
2) Updated {{filterFile}} would improve build times for all current plugin
versions, while update of each "client" plugin would take a while
3) While having this feature implemented at different levels (in both
maven-filtering, maven-jar, maven-assembly, etc) helps to cover more cases, I
would suggest still cover the very basic case in maven-filtering as a quick-win.
> 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)
