Create skywalking-java-commons sub project

[wu-sheng]

SkyWalking main repo's apm-common includes apm-datacarrier and apm-util. I am going to separate them into another repo and call it skywalking-java-commons.

In the future, everything commons in Java should be placed there.

[wu-sheng]

As all the codes have been running for a long time, we will use version 1.0.0 directly.

[wu-sheng]

FYI @apache/skywalking-committers

[kezhenxu94]

@wu-sheng How the backend and agent depend on this new sub project? Via git submodule or release it first?

[wu-sheng]

I prefer release first.(That is why I am planning to initial this repo in next days) What do you think?

[kezhenxu94]

Then we have to release it first every time when we add / modify codes in this new repo, which is painful, we should minimize the codes in this new repo.

I also checked classes in apm-util, only PropertyPlaceholderHelper is really shared between oap-server and agent, other classes are either only used in agent or oap-server, we can move them into agent or oap-server codebase respectively.

[kezhenxu94]

If submodule is not a blocker, I prefer using submodule

[wu-sheng]

The issue of submodule is in further release process. Both the agent and backend include the same maven module, they would conflict. How could we resolve that?

[wu-sheng]

We could do share nothing, and copy them into agent and backend core if we want, actually. If duplicate is not a concern.

[wu-sheng]

I am totally fine about withdraw this proposal, if we keep DataCarrier's source codes in both sides.

[kezhenxu94]

What I concern is, having this new sub repo will increase the maintainers' load, (not about maintaining codes, I mean releasing new versions)

We could do share nothing, and copy them into agent and backend core if we want, actually. If duplicate is not a concern.

In fact we don't need to "copy", we just push the original repo to the new agent repo, and delete everything that is not needed in the repo itself.

And according to #7553 (comment)

I also checked classes in apm-util, only PropertyPlaceholderHelper is really shared between oap-server and agent, other classes are either only used in agent or oap-server, we can move them into agent or oap-server codebase respectively.

As for the other module apm-datacarrier, I think we can leave it in 2 repos until we have time to replace it with Disruptor (we discussed this before, with @CalvinKirs, and I'm glad to do that when I have time).

[wu-sheng]

In fact we don't need to "copy", we just push the original repo to the new agent repo, and delete everything that is not needed in the repo itself.

Actually, this will not work. Because https://github.com/apache/skywalking/blob/master/apm-commons/apm-util/pom.xml this will trigger a new Maven central push in the release. We can't do it twice.
What I mean keep both and copy, is removing this at the both side, and move them into another package in the agent and server-util.

[kezhenxu94]

Actually, this will not work. Because https://github.com/apache/skywalking/blob/master/apm-commons/apm-util/pom.xml this will trigger a new Maven central push in the release. We can't do it twice.
What I mean keep both and copy, is removing this at the both side, and move them into another package in the agent and server-util.

Simply renaming the artifact id to like apm-util-oap / apm-util-agent can easily resolve the problem, without needs to rename the package, I don't think anyone would import apm-util-oap and apm-util-agent at the same time in a single project so we don't need to worry about package name conflicts.