有没有一种方法可以强制Maven增量复制资源文件夹更改? [英] Is there a way to force maven to copy resource folder changes incrementally?

问题描述

我正在使用Maven 2.2.1和m2eclipse.

I'm using Maven 2.2.1 and m2eclipse.

我有两个资源文件夹.

当我将更改保存到任何资源文件夹中的任何文件时，Maven增量构建开始，并将两个资源文件夹中的所有文件重新复制到目标文件夹.

When I save a change to any file in any of the resource folders, the Maven incremental build kicks off and re-copies ALL files in both resource folders to the target folders.

如果资源文件夹中文件的数量相对较少，则此行为会很好-但副本足以花费几分钟.

This behavior would be fine if there were a relatively small number of files in the resource folders - but there are enough that the copy can take several minutes.

是否有一种方法可以迫使Maven在其增量构建中更具选择性，并仅复制那些已更改的资源?

Is there a way to force maven to be more selective in its incremental build and copy only those resources that were changed?

推荐答案

我将问题归结为org.codehaus.plexus.util.FileUtils.copyFile()方法.这个方法被maven-resource-plugin调用以最终复制资源. copyFile()方法采用"overwrite"参数，资源插件会传入(默认确实为false)，但是......

如果传递的过滤器包装器列表为非空，则copyFile()方法忽略参数"overwrite"！而且，如果您已将资源的过滤设置为true，则此列表的确是非空的.

我可以理解copyFile()忽略'overwrite'的原因:仅仅因为目标文件是较新的并不意味着新的过滤文件将是相同的(即自您的资源文件以来变量的值可能已更改).最后一次过滤).
对于FileUtils实现者，忽略"overwrite"标志是方便的".但这付出了高昂的代价.单个资源文件的不必要更新可能会触发耗时但冗长的过程(即，在我的情况下，重建具有依赖关系的jar).这可能只有几秒钟，但足以破坏密集的代码编译测试周期的流程.

我在FileUtils上寻找打开的错误，但没有找到任何错误.这让我很烦，所以我不得不追逐它，但是现在我不能再花更多的时间了……几天之内，我想提交一个错误报告(也许可以更快地实现正确的解决方案)；如果有人可以发布指向适当的错误跟踪/报告系统的链接，我将不胜感激.

I chased the problem down to org.codehaus.plexus.util.FileUtils.copyFile() method. It is this method that is called by the maven-resource-plugin to ultimately copy the resource; the copyFile() method takes an 'overwrite' parameter, which the resource-plugin does pass in (and the default is indeed false), BUT...

The copyFile() method ignores the 'overwrite' parameter if the list of filter-wrappers passed is non-empty! And if you have filtering set to true for your resources, this list is indeed non-empty.

I can understand the reasoning behind copyFile() ignoring the 'overwrite': just because the destination file is newer does not mean that new filtered-file will be the same (i.e. the values for the variables in your resource file may have been changed since the last filtering).
Ignoring the 'overwrite' flag is "convenient" for the FileUtils implementor. But this comes at a great price; a single resource file unnecessarily updated can trigger off time-consuming but redundant processes (i.e. rebuilding a jar-with-dependencies in my case). This may only be a few seconds but can be enough to disrupt the flow of an intensive code-compile-test cycle.

I looked for open bug on FileUtils but did not find any. This was bugging me so I had to chase it down but I can't spend more time on it right now... in few days I would like to file a bug report (may just be quicker to implement the right solution); if anyone can post links to the appropriate bug-tracking/reporting system I would appreciate it.

这篇关于有没有一种方法可以强制Maven增量复制资源文件夹更改?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！