fix(common): handle spring-boot2/jersey dependency conflicts

[z7658329]

fix commons dependency conflicts and prevent future uncertainty issues.
also see: 445

[codecov]

Codecov Report

Merging #131 (549cdc7) into master (82f2a65) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master     #131   +/-   ##
=========================================
  Coverage     93.15%   93.15%           
  Complexity       65       65           
=========================================
  Files             9        9           
  Lines           263      263           
  Branches         22       22           
=========================================
  Hits            245      245           
  Misses            8        8           
  Partials         10       10           

Impacted Files	Coverage Δ
.../java/org/apache/hugegraph/version/RpcVersion.java	50.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[imbajin]

search CommonVersion class & also need update it

incubator-hugegraph-commons/hugegraph-common/src/main/java/org/apache/hugegraph/version/CommonVersion.java

Line 27 in 82f2a65

public static final Version VERSION = Version.of(CommonVersion.class, "1.0.0");

btw, we need a better way to modify the version, at least add a comment in pom for new devs?

@javeme or consider get the version/revision from pom.xml rather than class property? (Or remove common version check if not necessary)

[javeme]

If it is packaged in a jar, we cannot get the version from the pom.xml, so it fallback to the default version.

[imbajin]

If it is packaged in a jar, we cannot get the version from the pom.xml, so it fallback to the default version.

OK, we could consider these way: (way2 is the easiest)

1. check if somewhere possible for us to put the version into the jar file (like meta file/info of a jar?)
2. just leave a comment before revision param in pom file (devs could see the NOTE)
3. remove the common version check, seems it's not necessary to check it?

[z7658329]

also need to update RpcVersion.java

[javeme]

let's keep the status quo until we find a perfect way

[imbajin]

TODO: we need use one version in one project (currently could keep them..)

[z7658329]

CodeQL / Analyze (java) (pull_request) Step always failed cause timeout exception (tried 4 times), is there any way to avoid such problems？
@javeme @imbajin

[imbajin]

CodeQL / Analyze (java) (pull_request) Step always failed cause timeout exception (tried 4 times), is there any way to avoid such problems？ @javeme @imbajin

1. we could add a settings.xml for it to download the dependencies from different repo source
2. we choose to use our building command instead of auto-generated cmd, and use a param to specify the repo like mvn package -? aliyun.com (consider try this)
3. find a action to rerun it automatically (like auto retry 5 times if failed..)

[javeme]

let's keep the status quo until we find a perfect way

[z7658329]

always build error

[z7658329]

always build error

test in local, find that the grpc-core maven-metadata.xml file does not contains version 1.28.0, seems so strange!

i have ask in grpc community，see 10086

[z7658329]

upgrade grpc-core to 1.28.1, then build success !

[imbajin]

Good, and you could request review here