CURATOR-682: Use Gradle Enterprise Maven Extension to normalize Bnd-LastModified

[clayburn]

This change uses the Runtime classpath normalization feature of the Gradle Enterprise Maven Extension in order to better receive cache hits on surefire goals when the only change is to the Bnd-LastModified attribute of jar manifests.

To see the full impact of this change, one can run an experiment from this project's master branch, then from this project's branch. For this experiment, run two clean verify builds. The first build should populate the cache, while the second should read from the cache. On master, the experiment will show a cache miss. With this change, the experiment will show a cache hit.

[kezhuw]

The Gradle Enterprise Maven Extension offers the ability to cache the results of surefire tests. When the timestamp value of "Bnd-LastModified" is changing on every build, the cache is invalidated and a cache hit never occurs for these expensive tests.

On master, the experiment will show a cache miss. With this change, the experiment will show a cache hit.

Might be stupid, but I am lost in verify this. Are we going to "cache the results of surefire tests" ?

I think when we run tests, we are also test for concurrency and randomness or even flaky tests. Basically, I don't think we should do that if it is the intend.

For normal classes, I saw "Loaded from the build cache" in e44115e, which is HEAD^ of this pr, with clean "~/.m2/.gradle-enterprise/build-cache/v1/" directory and "mvn clean package -DskipTests", "mvn clean verify" in order.

[kezhuw]

I verified this with two successive mvn clean verify on HEAD of this pr. The last one completes without run tests. After changes to one test file in curator-recipes, mvn clean verify runs no tests from curator-framework.

I see the value of this pr(incremental test) and I think Gradle is building something great, but it cloud also puzzle people without any concepts of local cache (especially test cache ?). In most people's knowledge, mvn clean verify will run all tests from ground up. It would be really great that mvn clean cloud clean the corresponding test cache in this sense.

I think we can go with either way:

1. Document the local cache behavior(including this pr) and way to bypass or disable them.
2. Enable this through explicit configuration. I certainly want to taste it if we finally go this way and the "explicit" could be configurable.

@eolivelli @tisonkun What do you think ?

[eolivelli]

Thank for your contribution.

Curator is not that big and it is a OSS project, we should limit the number of third party maven plugins and add them only of strictly needed.
Once we add it it won't we easy to drop it.

I don't see much value on Curator for this patch, especially as I usually use my IDE to run the tests and I see all tests running only on CI.

So I am not supportive of this patch, but I won't block it if there are other people who think it is a good addition to our build toolkit

[tisonkun]

I second @eolivelli's suggestion that we may not need this "improvement" as YAGNI.

[clayburn]

Thanks, I will close it then.