search

layotto / java-sdk

java sdk for layotto
8 stars 13 forks source link

Let `sdk` and `sdk-reactor` reuse common code #3

Open seeflood opened 2 years ago

seeflood commented 2 years ago

Let sdk and sdk-reactor reuse common code and reduce redundencies.

See https://github.com/mosn/layotto/pull/349#discussion_r762834687

kevinten10 commented 2 years ago

Can I put the entity class in the common part first?

seeflood commented 2 years ago

@kevinten10 Do you mean the request and response object under the domain package? image Sure ! Since the domain objects in spec/sdk/runtime/v1/domain have already been used by users(except the lock related objects,e.g. TryLockRequest ),please keep them compatible when refactoring the code. For example,we should keep the existing fields and package name of the objects in spec/sdk/runtime/v1/domain not changed after moving them into a new module. Of course , we can add new fields in them.

seeflood commented 2 years ago

image

kevinten10 commented 2 years ago

Yes, I will keep the unchanged of sdk-runtime.

I plan to move all the definitions of all Entity and Runtime interfaces to the sdk-domain module, which will be consistent with the current sdk-runtime module, and then the sdk-reactor module also uses these definitions.

Then define the RxRuntime interface Extends Runtime interface and add Reactor's API implementation.

At the same time, the sdk-domain will use reactor-core with compile scope, which will not affect users who use non-reactor sdk.

At present, I am doing these work.

seeflood commented 2 years ago

@kevinten10 Thanks for your details! I try to draw a picture to illustrate your design: image Is my understanding correct?

At the same time, the sdk-domain will use reactor-core with compile scope, which will not affect users who use non-reactor sdk.

I didn't understand.From my understanding, if we configurate the maven dependency to be compile scope, users who use non-reactor sdk will also be affected. Could you give more details?

kevinten10 commented 2 years ago

Give me some time for me to try, how can the dependencies in the SDK not propagate to the dependencies of the application

seeflood commented 2 years ago

image @kevinten10 Maybe this way? Extract the common domain objects into a new module and leave those not common in their own module

kevinten10 commented 2 years ago

All right! I will refactor it in #7