> On 25 Apr 2020, at 15:37, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
>
> 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.
Great! It’s been a couple of years since I’ve worked on a maven project so
pointers towards infrastructure pieces I’ve missed or forgotten is v helpful!
I’ll take a look at the incremental build helper.
> 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)
I’m not totally sure of this. Filtering, for example, is particularly dependant
on properties and configuration which aren’t directly linked with a source file
change. Allowing the feature to consider wider inputs should make the feature
more reliable, and might avoid the need to make it optional. Definitely up for
running the numbers and seeing the impact before deciding though!
> 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).
Interesting. To me the the default should be that nothing is repeated. Our
experiences of Gradle are entirely opposed too - I’ve never seen it’s
incremental build support doing the wrong thing. I’m well aware of the
necessity to support timestamps when filtering though.
> 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.
Yeah, that’s all looking much closer to what I’ve used in Gradle more recently.
It would make it a bigger piece of work, but I’m happy to explore that if it’s
the preferred option!
Thanks for the input!
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
