[MBUILDCACHE-48] - Add possibility to disable caching per module in a multi-module project

[eltsovalex]

Added a new flag that allows disabling cache (not just looking up build artifacts, but all the build cache completely).
This may be required in a case when a module is a final leaf of a reactor tree, and its artefacts are not required by other modules as cached dependencies. Hence eliminating some modules from caching will speed up build and also lower the footprint size of a cached build.

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MNG-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MNG-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the
  commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

[AlexanderAshitkin]

Hi Alex.
Regarding the code itself - looks good to me. But please clarify the use case and rationale for the change. Is it for cases where the local build is faster than downloading from the cache? I understand uploading might be expensive, but an existing configuration parameter allows for skipping the upload. And if uploading doesn't happen, I wonder what the benefits are achieved by disabling the cache compared to disabled upload.
Thank you!

[eltsovalex]

Hi Alex. Regarding the code itself - looks good to me. But please clarify the use case and rationale for the change. Is it for cases where the local build is faster than downloading from the cache? I understand uploading might be expensive, but an existing configuration parameter allows for skipping the upload. And if uploading doesn't happen, I wonder what the benefits are achieved by disabling the cache compared to disabled upload. Thank you!

Hi. Thanks for asking. Sorry for not providing a precise description of my use-case.
So, I have a module in my project that builds a huge EAR of ~200Mb as a target. Due to some specific reasons (e.g. project version written deep down in one of jars inside EAR +some build artifacts required for publishing by CI to be present in target folder) I have to always build that subproject clean (so without caching). And while the previous flag I added last year (maven.build.cache.skipCache) works fine to solve the forced rebuild task - it still uploads the 200Mb EAR to cache. So it spoils the caches (both local and remote) with multiple versions of a huge unused file + takes some time for the upload itself. As this is not an attached artefact, but a main goal - so I can not add it to ignored/not uploaded.
Hence this new property added that totally disables cache on a per-project level (both lookup and upload to both caches) - but not globally (which is different from existing flags AFAIK)

[olamy]

worth to document the behaviour https://maven.apache.org/extensions/maven-build-cache-extension/parameters.html
e.g this parameter can apply to single module(s) as well.