> On 29 Apr 2020, at 14:43, Tobias <tobn...@freenet.de> wrote:
>
> Hi,
>
> I just came across this issue the other day, too. A mvn install after a
> mvn clean install, i.e. nothing has to be compiled, results in a jar
> being created for one module which takes one minute. This is due to
> filtered resources being overwriten though this is not necessary. This
> happens for multiples modules in our build. I too think that the speed
> of the build process could be greatly improved if resources wouldn't be
> overwriten if nothing has changed.
>
>> I think we’re doomed to having to recreate the file each time, because we
>> have no way of knowing whether the file has changed until you generate it.
>
> I'm new to Maven and just discovering it, but my sketch of a naive and
> simple, not optimized idea was the following:
>
> - Identify all locations where information can be stored which is used
> to generate filtered resources (pom.xml, .properties files, ...?)
> - For all these locations, get the date it was last written to
> - Take the most recent date from all these dates
> - For each filtered resource which is already in the target folder from
> the last build, take the date of this resource file and check if this
> date is newer than the date identified in the previouis step. If it is,
> don't copy the filtered resource to the target folder
>
> Is this not possible?
If we need to look at all potential sources of filterable properties then that
will include environment variables which aren’t necessarily associated with a
file, and potentially properties that include a timestamp and will necessarily
be different every run, so using the lastModified date of some set of input
files is not practical.
I’ve opened a pull request using a temporary file to write filtered content to,
and compare with the previous result. If the contents are equal then the
temporary file is deleted and the target file is left unmodified, otherwise we
rename the temporary file over the target, updating its lastModified date
implicitly. This approach requires no knowledge of what filtering was
performed, or where those properties came from.
Admittedly it means that the Maven Filtering Plugin is still doing a little
more IO work each run, and it temporarily consumes 2x the storage in the target
volume, but filtered resources tend to be small and disk space is relatively
cheap so I think this is acceptable. This approach does recreate _a_ file each
time, but avoids recreating _the_ file each time, and can avoid triggering
downstream work based on the lastModified date.
I think this is the simplest and least risk solution, and doesn’t preclude
trying something fancier later.
https://github.com/apache/maven-filtering/pull/5
Feedback welcome!
Thanks,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
