Two separate `mvn` runs open possibility for dependecny tree be resolved differently during actual build than when computing hashvers

[avodonosov]

The fact that we calculate hashvers and execute actual build in in a separate mvn runs opens chance for maven to resolve dependency differently during actual build than for hashversion compuatation - during the second run maven could receive newerver version of some external dependency from online repo.

I've been thinking how to prevent this, but also came to opinion this is not really critical problem, for CI / ticket branch builds the behaviour should be fine.

If the dependency tree is calculated differently during actual build, this means we annotate some artifact with a hashversion representing one dependency tree, while in reality it is build with different dependency tree. Note, the discrepancy can only affect external libraries in the dependency tree. Then, when we try to deploy and run a build of our system, it is assembled from artifacts of several hashver builds (the modules optimized away from this build are taken from previous builds). The matching hashversions are expected to represent exactly same set of 3rd party library versions, but actually get some of the modules that were built with different set of 3rd parrty libraries.

If the modules of our system are independent applications (.war files, or uberjars, that include all dependencies), then the applications deployed may have different 3rd party libs inside. But it's very unlikely this will break interoperation between apps, because any dependency important for cross-component communication in the system will normally be explicitly mentioned in the applciation pom file, while the discrepancy that we risk in this issue only happens in indirect parts of the dependency tree, and this discrepancy is constrained by the dependency requirement in application pom.

If the modules of our system are shared libraries, their actual use will happen in context of some application built later by the library user, and their actual runtime dependencies will be determined by the dependency resolution during that build.

Given all that, even production use of the current approach should be fine, not only CI builds.

Thoughs about fixing this issue:

• Use maven-dependency-plugin:go-offline action before the build, and then run both hashver computation and the actual build in offline mode. However, maven-dependency-plugin:go-offline and it's constituents dependency:resolve and dependency:resolve-plugins are completely broken, they fail with errors on projects that build successfully in online mode, do not fetch all dependencies (https://www.mail-archive.com/users@maven.apache.org/msg142843.html). In the maven-dependency-plugin Jira I found advice to use go-offline-maven-plugin instead, but it also has problems (qaware/go-offline-maven-plugin#23)
• Add a validation action to be used during the actual build that will re-compute hashvers and verify they are equal to ones we have in the targer/hashversions.properties
• ...