Hi Robert, two thoughts maybe 1. all that work (thinking also of assembly one) should probably end up by enriching https://github.com/apache/maven-shared-incremental/blob/master/src/main/java/org/apache/maven/shared/incremental/IncrementalBuildHelper.java model and impl. I tend to think it does not need any hash but just a lastUpdated track (the most recent file invalidating previous cache, it is enough and faster than any hash computation) 2. by default nothing should be skipped - I guess a -Dxxx.incremental=true should be added, maybe even to maven core (see next point), all this theory is based on fully defining inputs/outputs fully. This is what gradle implemented and I almost never saw a single complex gradle build correctly configured to not bypass modules it shouldn't bypass (or worse, skip tests it shouldn't) so I think we should be conservative here + several plugins refetch data when executed so even if the result of 1 is "no change" you can need to reexecute the plugin (including the filtering one if the filtered data depends on the time or so - I don't want to discuss it is a good or bad practise but it is used a lot in CI/CD pipelines). 3. Not being per plugin but global on maven sounds better than starting to be specific in all plugins. I really see it as a dev feature you can activate while working and not enable on the CI for example. Added to maven-core it can enable to define in mojo the preconditions which would be checked with 1 and potentially the conditions triggering inconditionally a rebuild. Maybe a @MojoInput("${project.build.outputDirectory}", "${project.artifacts}", "method:getState()") or so.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le sam. 25 avr. 2020 à 16:25, Robert Oxspring <roxspr...@imapmail.org> a écrit : > Hi > > “mvn clean install” is definitely normal for small projects like maven > plugins because it’s a cheap way of guaranteeing your build is up to date. > > For developers working on larger projects “mvn clean install” is typically > avoided wherever possible as it forces everything to be rebuilt even when > just a couple of lines of code have been changed. Instead folks rely on > “mvn install” doing the least work practical to incrementally bring the > target directory up to date. > > In complex multi-module builds its common for one modules filtered > resources to be treated as inputs to later processes. At the moment, the > filtering plug-in unconditionally overwrites resources such that the > filtered output file is newly modified. This means that downstream > processes see their inputs as newly modified and have to assume their > outputs are outdated and need to be rebuilt. > > (Of course, in CI environments the opposite tradeoff is normal: accept > slower builds in return for guaranteed clean reliable ones!) > > At work, a “mvn install -DskipTests” on our multi-module project takes > minutes even when nothing has changed, when I think it could be finished in > seconds. So far I’ve identified the filtering and assembly plugins as > triggers of unnecessary work and am trying to offer fixes to optimise that > behaviour! > > That context help at all? > > Thanks, > > Rob > > > On 25 Apr 2020, at 14:37, Slawomir Jaranowski <s.jaranow...@gmail.com> > wrote: > > > > Hi, > > > > Can you describe your case and what you want to achieve. > > > > By default all files created during maven running are write to target > > directory. And in most case target directory is cleaned before new build > > starting. > > Usual maven is running by: > > mvn clean install. > > > > sob., 25 kwi 2020 o 00:59 Robert Oxspring <roxspr...@imapmail.org> > > napisał(a): > > > >> Hi all, > >> > >> > >> When copying resources with filtering on, files are always overwritten > >> even when the filters have not changed. I’d like to change this such > that > >> repeated filtering copies do not modify the destination file. > >> > >> I’ve prepared a change to write the filtered content to a temporary file > >> and only rename that over the destination if they’re different: > >> > >> > https://github.com/apache/maven-filtering/compare/master...roxspring:feature/avoid-overwrite-on-no-op-filter > >> > >> Would something like this be acceptable? I’m guessing the next step is > to > >> create an issue in Jira? - agains MNG?? > >> > >> Thanks, > >> > >> Rob > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > -- > > Sławomir Jaranowski > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
