You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@kevinten10 Do you mean the request and response object under the domain package?
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.
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.
@kevinten10 Thanks for your details!
I try to draw a picture to illustrate your design:
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?
Activity
kevinten10 commentedon Dec 8, 2021
Can I put the
entityclass in the common part first?seeflood commentedon Dec 8, 2021
@kevinten10 Do you mean the request and response object under the
domainpackage?Sure !
Since the domain objects in
spec/sdk/runtime/v1/domainhave 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/domainnot changed after moving them into a new module. Of course , we can add new fields in them.seeflood commentedon Dec 8, 2021
feat: layotto#3 and layotto#1
kevinten10 commentedon Dec 11, 2021
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-domainmodule, which will be consistent with the currentsdk-runtimemodule, and then thesdk-reactormodule also uses these definitions.Then define the
RxRuntimeinterface ExtendsRuntimeinterface and add Reactor's API implementation.At the same time, the
sdk-domainwill usereactor-corewith compile scope, which will not affect users who use non-reactor sdk.At present, I am doing these work.
seeflood commentedon Dec 12, 2021
@kevinten10 Thanks for your details!
I try to draw a picture to illustrate your design:
Is my understanding correct?
I didn't understand.From my understanding, if we configurate the maven dependency to be
compilescope, users who use non-reactor sdk will also be affected. Could you give more details?kevinten10 commentedon Dec 12, 2021
Give me some time for me to try, how can the dependencies in the SDK not propagate to the dependencies of the application
seeflood commentedon Dec 13, 2021
@kevinten10 Maybe this way? Extract the common domain objects into a new module and leave those not common in their own module
kevinten10 commentedon Dec 14, 2021
All right! I will refactor it in #7