refact: adapt apache package and dependency in all modules (Breaking Change) by z7658329 · Pull Request #2019

refact: adapt apache package and dependency in all modules (Breaking Change) by z7658329 · Pull Request #2019 · apache/hugegraph

javeme previously approved these changes Nov 18, 2022

@z7658329 can we move the CodeQL fixes into a separate PR?

@z7658329 can we move the CodeQL fixes into a separate PR?

i have fixed, but in ci progress ,
hugegraph-ci / build (rocksdb, 11) (pull_request) failed, should rerun it , @javeme @imbajin see :

javeme previously approved these changes Nov 20, 2022

some TODOs & Warning:

the APIVersion now is 0.67, shall we keep it?
CommonVersion

@javeme why we need check common's version?

imbajin changed the title ~~adapt apache package and dependency~~ refact: adapt apache package and dependency in all modules (Breaking Change)

Nov 22, 2022

the APIVersion now is 0.67, shall we keep it?
- yes we need to keep it, api version must increase forever.
why check common's version?
- to avoid importing two different common jars with conflict versions.

why check common's version?
: to avoid importing two different common jars with conflict versions.

What does this mean? At present, the whole project seems to have only one huge-common dependency

What does this mean? At present, the whole project seems to have only one huge-common dependency

someone may import hg as a lib, at the same time also has imported hg-common.

What does this mean? At present, the whole project seems to have only one huge-common dependency

someone may import hg as a lib, at the same time also has imported hg-common.

Seems it should be handled by users(like use a fixed version or exclude the duplicate one), and currently it have 2 problems:

the check fails when the version is 1.0.0 but the range is 2.x~2.x
how to set the new version? (because the old common also use the 1.x & 2.x as their version num)

consider handle this in a separate PR

imbajin previously approved these changes Nov 22, 2022

javeme previously approved these changes Nov 22, 2022

		@@ -130,16 +82,16 @@

		<dependencyManagement>
		<dependencies>
		<!-- hugegraph-commons -->
		<!-- TODO: could we merge them to hugegraph-commons only? -->

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no we can't merge them, because in some scenarios it is not necessary to import both the two packages at the same time, like client or loader.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, change the comment in next PR (could modify the common version together @z7658329 )

What does this mean? At present, the whole project seems to have only one huge-common dependency

someone may import hg as a lib, at the same time also has imported hg-common.

Seems it should be handled by users(like use a fixed version or exclude the duplicate one), and currently it have 2 problems:

the check fails when the version is 1.0.0 but the range is 2.x~2.x

how to set the new version? (because the old common also use the 1.x & 2.x as their version num)

consider handle this in a separate PR

so the VersionTest.testCoreVersionCheck successed! we need update commons jar? @javeme @imbajin

in dubbo project, use like this:

see : apache/hugegraph-commons#119

TODO: and we need also check the 0.69 in pom

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use rebase and merge